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I .  INTRODUCTION 


The  purpose  of  this  report  is  quite  limited,  viz.,  to  pro¬ 
vide  a  concise  compendium  of  input  commands  and  formats  for  the 
Army  Unit  Resiliency  Analysis  (AURA)  computer  code.  It  is 
assumed  that  the  reader  is  reasonably  familiar  with  the  AURA  fam¬ 
ily  of  methodologies  in  general,  and  with  the  purpose  and  func¬ 
tion  of  the  many  options  of  the  AURA  code  itself.  Therefore, 
only  a  brief  description  of  command  functions  will  be  given  with 
each  entry.  For  more  information,  the  user  is  referred  to  the 
Introduction  to  the  Use  of  AURA  report. 

The  command  descriptions  in  this  report  are  grouped  by  func¬ 
tion:  those  that  describe  assets  are  presented  together,  fol¬ 
lowed  by  those  that  describe  threat  weapons,  etc.  The  groupings 
and  corresponding  sections  are  listed  in  Table  l.  Within  each 
grouping,  the  entries  are  arranged  alphabetically. 


TABLE  1.  GROUPINGS  OF  COMMANDS  FOR  THIS  REPORT. 


SECTION 

GROUPING 

A 

EXECUTION 

B 

GENERAL  RUNSTREAM  INFORMATION 

C 

NAMES 

D 

ASSET  INPUTS 

E 

DEPLOYMENT  INPUTS 

F 

WEAPON  INPUTS 

G 

WEAPON  EFFECTS  INPUTS 

H 

UNIT  FUNCTION  INPUTS 

I 

PROGRAM  CONTROLS 

1.  Reference:  J.T.  Klopcic  and  L.K.  Roach, "An  Introduction  to 
the  Use  of  the  Army  Unit  Resiliency  Analysis  (AURA)  Metho¬ 
dology:  Volume  I,"  BRL-MR-3384.  (SEP84) .  AO  F300493. 


II.  AURA  INPUT  OPTIONS 


A.  Execution 

It  is  generally  convenient  to  assemble  the  commands  and  data 
for  an  AURA  run  in  a  file  (hereafter  called  the  RUNSTREAM) .  It 
is  therefore  necessary  to  redirect  the  computer  input  from  its 
normal  input  channel  to  the  RUNSTREAM.  For  this  purpose,  an  AURA 
execution  input  stream  requires  one  card  containing  the  name  of 
the  runstream  file.  (In  this  report,  the  term  "card"  will  refer 
to  a  single  input  line.) 

Optionally,  two  more  cards  may  be  entered.  If  a  second  card 
is  read  from  the  normal  input  channel,  it  is  interpreted  as  a 
heading  to  be  printed  at  the  beginning  of  the  AURA  output  and 
again  at  the  beginning  of  the  results  summary.  If  a  third  card 
is  read,  it  is  interpreted  as  a  deployment  offset.  (Both  head¬ 
ings  and  offsets,  which  can  also  be  input  via  the  RUNSTREAM,  are 
described  in  the  following  sections.  See  HEADING  and  OFFSET  in 
sections  I  and  E  respectively.) 

Format ; 

name  of  runstreaT'.  file 

heading  information  (  80  character  maximum  ) 
x-offset,  y-offset  (REAL) 

B.  General  Information 

1.  Formats.  All  AURA  data  sets  are  preceded  by  a  mnemonic  con¬ 
trol  card  and  followed  by  an  END  card.  For  example,  the  mnemonic 
control  to  input  deployment  data  is  "DEPLOYMENT".  Depending  on 
the  particular  mnemonic,  several  cards  of  data  may  then  follow: 
the  most  recent  mnemonic  "remains  in  effect"  until  ENDed  or 
superseded.  Thus,  if  several  pieces  of  data  are  appropriate  for 
a  particular  mnemonic  (e.g.  several  items  are  to  be  deployed) , 
the  DEPLOYMENT  mnemonic  need  only  appear  once,  followed  by 
several  cards  of  deployment  data. 

Each  data  set  should  end  with  an  END  card.  However,  if  an 
END  card  is  missing,  the  input  routine  will  detect  the  following 
mnemonic  control  card  and  begin  a  new  data  set. 

Mnemonic  control  cards  may  be  abbreviated  to  the  first  six 
letters. 

2.  Order.  With  few  exceptions,  the  various  data  sets  may  be 
input  in  any  order.  Furthermore,  although  not  advised,  data  of  a 
particular  type  can  be  input  in  several  sets  (each  preceded  by 
the  particular  mnemonic) .  The  major  exceptions  to  the  any-order 
rule  are: 

a.  The  first  data  set  must  be  the  NAMES  data  set. 


b.  Functional  forms  (LINKS,  SUBCHAINS,  ORLINKS,  COMPOUND 
LINKS)  must  be  Input  before  any  higher  level  functional 
forms  (SUBCHAINS,  ORLINKS,  COMPOUND  LINKS,  CHAINS)  which 
use  them. 

3.  Data  Forms.  All  AURA  data  cards  are  in  one  of  three  forms: 

TYPE  DESCRIPTION 

HR  All  Hollerith  (text)  words  or  names,  with  each  set 

of  words  or  names  separated  by  a  comma.  (NOTES: 
Embedded  commas  are  not  allowed.  Leading  blanks 
are  ignored.) 

RO  All  numbers  separated  by  blanks  or  commas. 

R1  One  set  of  words  or  name  followed  by  numbers.  The 

words/name  must  be  separated  from  the  numbers  by  a 
comma;  the  numbers  may  be  separated  from  each 
other  by  blanks  or  commas. 

4.  Number  Types.  Numbers  in  AURA  are  either  INTEGERS  or  REALS. 
(REALS  are  floating  point  numbers  or  exponential  numbers  with 
decimal  points) .  AURA  checks  to  assure  that  the  anticipated  com¬ 
bination  of  INTEGERS  and  REALS  is  input  and  will  terminate  a  run 
on  a  FATAL  FORMAT  ERROR  if  an  errant  combination  is  detected. 
The  following  sections  specify  the  types  of  numbers  anticipated. 


5.  Spseial  Charaotars. 

(a)  Continuation  cards.  Data  may  be  continued  on  a  evibse- 
guent  card.  A  continuaticm  card  is  denoted  by  a  dollar  sign  ($} 
as  the  first  character  on  the  card,  followed  by  data  in  format 
HR,  RO,  or  R1  as  appropriate.  A  comma  may,  but  need  not,  follow 
the  dollar  sign. 

Continued  data  falls  Into  two  types:  supplementazry  data 
(data  that  Is  different  from  that  of  the  preceding  card)  and 
overflow  data  (of  the  same  type  which  did  not  fit  on  the  preced¬ 
ing  card) .  Several  data  sets  allow  options  which  must  be  entered 
on  supplementary  continuation  cards.  For  example,  to  specify  an 
alternate  posture  for  a  deployed  asset,  the  deployment  data  card 
is  followed  by  a  supplementary  continuation  card  containing  the 
alternate  posture  code  and  mean-time-to-change. 

(b)  Comments.  The  pound  sign  (#)  immediately  stops  the 
scan  of  a  card  by  the  AURA  read  routines.  Thus  the  user  can 
Insert  comment  cards  (for  his  own  use,  not  to  be  read  as  data) 
into  an  AURA  runstream  by  beginning  the  card  with  a  pound  sign. 
Similarly,  any  data  card  can  have  a  comment  appended,  as  shown 
below. 

#THIS  IS  AN  EXAMPLE  OF  COMMENTS  IN  A  RUNSTREAM 

DEPLOYMENT  I  BASED  ON  FM  -  XYZ 

MECHANIC,  100.,  352.,  1.0,  1,1, 1,1, 1,0  #  MOTOR  POOL 

(c)  Functional  structure  names.  As  described  in  the  fol¬ 
lowing  sections,  names  for  the  SUBCHAIN,  ORLINK,  and  CPLINK  func¬ 
tional  structure  begin  with  *,  4,  and  I  respectively. 

(d)  Imbedded  procedure  commands.  Anticipated  extensions  of 
the  AURA  input  routines  Include  the  development  of  imbedded  pro¬ 
cedures,  which  will  be  signified  by  a  baclcslash  (\)  in  column  1. 
An  example  of  such  a  procedure  is  the  Imbedded  offset  (under 
DEPLOYMENT)  which  translates  blocks  of  data. 


6.  Tttrms  Used  in  the  Following  sections. 

ASSETS:  Personnel  and  items  of  equipment.  The  term  "asset”  is 

generally  used  when  referring  to  the  physical  attributes 
of  an  item  in  a  unit. 

WEAPONS:  Incoming  weapons.  The  term  "weapon"  includes  warheads 

and  delivery  systems. 

MISSION:  Performance  rate  or  capability  upon  which  the  study 

unit  is  being  evaluated.  For  example,  a  supply  unit 
might  be  evaluated  on  its  ability  to  issue  20000  tons  of 
supplies  per  day. 

FUNCTIONAL  STRUCTURE:  The  organization  of  activities  and  tasks 

that  result  in  the  accomplishment  of  a  unit's  mission(s) . 
Note  that  the  functional  structure  is  made  up  of  JOBS 
that  are  done,  not  the  ASSETS  that  do  them.  (The  connec¬ 
tion  between  job  positions  and  assets  that  can  fill  the 
positions  is  made  through  the  LINKS  input.) 

It  is  convenient  to  consider  the  functional  structure  for 
a  mission  as  being  constructed  through  three  levels  of 
aggregation.  The  lowest  delineation  of  subtasks  or  job 
positions  is  called  a  LINK.  For  example,  one  might 
define  a  radio  operator's  job  as  a  LINK  if  one  were  not 
concerned  with  subtasks  within  the  job. 

Jobs  combine  together  in  different  ways  to  perform  the 
various  activities  that  go  on  within  a  unit.  For  exam¬ 
ple,  an  artillery  unit  might  have  several  activities 
going  on  at  one  time  during  a  fire  mission:  firing, 
loading,  fire  direction  calculating  and  new  position 
reconnaissance.  The  AURA  name  for  such  an  activity  is 
called  a  SEGMENT.  SEGMENTS  are  made  up  of  LINKS;  how¬ 
ever,  the  various  LINKS  within  a  SEGMENT  may  be  combined 
to  show  different  relationships.  Thus,  a  SEGMENT  may  be 
a  single  job  (LINK) ,  a  group  of  jobs  that  must  be  done 
together  (SUBCHAIN) ,  a  choice  between  groups  of  jobs 
(ORLINK)  or  several  groups  of  jobs  such  that  the  total 
activity  is  a  summation  of  the  independent  contributions 
of  the  different  groups  (COMPOUND  LINK) . 

The  essential  feature  of  SEGMENTS  is  that  they  all  con¬ 
tribute  to  the  mission  in  such  a  way  that  mission  accom¬ 
plishment  is  limited  by  the  weakest  SEGMENT.  The  collec¬ 
tion  of  SEGMENTS,  which  span  the  activities  of  the  unit 
toward  mission  accomplishment  is  called  a  CHAIN,  the 
final  level  of  aggregation  in  the  AURA  functional  struc¬ 
ture  model. 

A  more  complete  description  of  the  AURA  functional  struc¬ 
ture  is  given  in  Appendix  B. 
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HOMELINK:  A  link  which  has  the  same  name  as  an  asset  is 

referred  to  as  that  asset's  "homellnk."  An  asset  is 
immediately  available  for  its  homelink  task  and  contri¬ 
butes  to  its  accomplishment  at  100  percent  effectiveness. 
An  asset  has  priority  for  assignment  to  his  own  homelink. 
However,  this  priority  may  be  violated  if  the  asset  is 
needed  elsewhere,  or  is  too  ill  to  perform  at  an  accept¬ 
able  level.  (See  Allocation  Algorithm  Decision  Rules, 
next  section.)  Any  asset  which  does  not  have  a  link  of 
the  same  name  is  assigned  the  homelink  NOLNK. 

DUMMYLINK:  A  link  which  has  no  asset  of  the  same  name  is  called 

a  "dummy  link."  Dvimmylinks  are  jobs  which  do  not  have  a 
particular  asset  assigned  to  them,  but  are  filled  —  when 
needed  —  by  sxibstitutes . 

7.  Allocation  Algorithm  Decision  Rules.  The  decision  rules  fol¬ 
lowed  by  the  asset  allocation  algorithm  (the  "commander")  in 
assigning  assets  to  LINKS  are  as  follows: 

HOMELINK.  A  LINK  is  filled  by  its  homelink  asset  (an  asset  hav¬ 
ing  the  same  name  as  the  LINK)  if  one  is  available.  If 
no  homelink  asset  is  available,  the  commander  will 
attempt  to  fill  the  link  with  a  substitute.  Also,  if  the 
available  homelink  asset  is  degraded  (e.g.  because  of 
sickness  or  fatigue)  below  a  user-settable  level  (sicklv) 
and  if  there  is  a  substitute  available  at  a  performance 
level  more  than  (1/sicklv)  greater  than  the  best  homelink 
asset,  then  a  substitute  will  be  selected. 

SUBSTITUTES.  A  potential  substitute  does  not  become  available 
until  the  elapsed  time  (time  since  the  need  for  a  substi¬ 
tute  developed)  exceeds  the  svibstltute's  (user-specified) 
substitution  time.  (See  LINKS,  section  H.4.)  If  more 
than  one  substitute  is  available  in  the  elapsed  time 
Involved,  a  particular  substitute  is  chosen  by  the  fol¬ 
lowing  criteria. 

a.  Any  potential  substitute  which  is  more  than  a  user- 
settable  level  (slgnlf)  less  effective  than  the  best  sub¬ 
stitute  is  automatically  dropped  from  consideration. 

b.  The  commander  will  assign  a  less  versatile  asset  in 
preference  to  assigning  a  more  versatile  asset.  (Versa¬ 
tility,  an  Integer  number,  is  defined  as  the  nximber  of 
LINKS  to  which  an  asset  can  be  assigned.  AURA  Internally 
predetermines  the  versatility  of  each  asset  by  analysis 
of  the  svibstltutlon  matrix.) 

c.  The  allocation  algorithm  numbers  the  substitutes  for 
a  particular  LINK  in  the  order  in  which  they  were  named. 
(See  LINKS,  section  H.4.)  The  commander  will  assign  an 
lower-numbered  substitute  in  preference  to  a  higher- 
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numbered  one.  (Note,  however,  that  several  assets  may 
have  equal  order  numbers,  since  several  substitutes  may 
be  specified  by  the  same  common  name.  See  NAMES,  section 
C.) 


The  normal  operation  of  the  allocation  algorithm  is  to  take 
the  decision  criteria  in  the  order  presented  above:  a  decision 
passes  to  the  next  criterion  only  if  there  is  a  "tie"  in  all 
preceding  criteria. 

The  decision  rules  and  values  can  be  modified  by  the  user. 
As  stated  above,  the  user  can  set  the  values  of  signlf  and 
sicklv.  Furthermore,  the  order  of  consideration  of  criteria  2 
and  3  (VERSATILITY  and  USER-INPUT-OROER)  can  be  reversed.  See 
DECISION  RULES,  section  I.l. 

Finally,  note  that  any  decision  made  by  the  ed>ove  rules  can 
be  over-ruled  by  a  correction  made  through  the  look-back  capabil¬ 
ity  of  the  algorithm.  For  a  more  detailed  discussion  of  the  AURA 
Asset  Allocation  Algorithm,  see  Appendix  B. 

8.  Coordinate  Systems.  Three  natural  coordinate  systems  are 
used  in  AURA  to  express  data  that  refers  to  geographical  loca¬ 
tions  or  extents. 

(a)  The  UNIT  Coordinate  System.  Any  right-handed  coordi¬ 
nate  system  may  be  used  to  lay  out  the  study  unit.  Any  particu¬ 
lar  point  in  the  unit,  such  as  the  geographical  center  or  "lower 
left"  comer,  may  be  designated  as  the  origin  of  the  UNIT  Coordi¬ 
nate  system,  and  all  other  unit  elements  are  deployed  relative  to 
that  point. 

(b)  The  INCOMZMC  FIRE  (RANGE-DEFLECTION)  System.  Threat 
weapon  parameters  are  specified  in  RANGE  and  DEFLECTION,  where 
RANGE  is  in  the  direction  of  the  Incoming  fire,  and  DEFLECTION  is 
normal  to  RANGE  such  that  RANGE-DEFLECTION  define  a  right-handed, 
horizontal  coordinate  system.  The  user  can  specify  the  orienta¬ 
tion  of  the  RANGE  direction  relative  to  the  UNIT  Coordinate  sys¬ 
tem.  (See  INCOMING  FIRE,  section  F.6.) 

(C)  The  WIND  DIRECTION  (DOWNWIND-CROSSWIND)  System.  Toxic 
cloud  dispersion  is  specified  in  the  DOVTNWIND  and  CROSSHIND 
directions,  which  are  defined  to  form  a  right-handed,  horizontal 
coordinate  system.  (The  NUSSEII  standard  toxic  dispersion  code 
uses  this  coordinate  system:  Thus,  no  adjustments  are  necessary 
to  use  NUSSEII  data  in  AURA.)  The  user  can  specify  the  orienta¬ 
tion  of  the  DOWNWIND  direction  relative  to  the  UNIT  Coordinate 
system.  (See  WIND  DIRECTION,  section  F.IO.) 

9.  Units,  Times  and  Time  Intervals.  Much  of  the  data  which  is 
input  into  AURA  has  associated  units,  most  commonly  length  or 
time.  It  is  essential,  therefore,  to  establish  a  consistent  sys¬ 
tem  of  units,  since  parameter  values  can  be  markedly  different  in 


7 


different  systems.  (For  example,  an  event  time  could  be  Input  as 
3600.,  60.,  or  1.  depending  on  whether  seconds,  minutes  or  hours 
are  being  used.) 

With  the  exception  of  certain  nuclear  algorithms  which  con¬ 
tain  built-in  basic  data,  AURA  can  be  used  with  any  consistent 
set  of  units.  However,  achieving  such  consistency  may  require  a 
great  deal  of  thoroughness.  For  example,  both  length  and  time 
are  burled  In  the  threshold  value  for  chemical  alarm  functioning. 
We  therefore  recommend  the  following  set  of  units,  consistent 
with  the  nuclear  algorithms: 


Times: 

minutes 

Distances: 

meters 

Toxic 

mgm-min/m**2 

The  following  units  are  essential 

Angles: 

degrees 

Nuclear 

rads  (cGy) 

Nuclear 

kt 

Some  of  the  AURA  options  require  the  Input  of  a  time  dura¬ 
tion.  For  example,  to  allow  Individuals  under  attack  to  change 
posture  requires  specifying  the  mean  time  for  the  change.  On  the 
other  hand,  those  options  which  result  in  the  scheduling  of  an 
event,  such  as  the  options  which  specify  that  an  attack  will 
occur,  require  input  of  an  absolute  (clock)  time  into  the  simula¬ 
tion.  In  this  report,  all  time  Inputs  will  be  Identified  as 
(intrvl)  or  (clock)  to  indicate  whether  the  value  is  a  duration 
interval  or  an  absolute  event  time. 

10.  Alphabetical  Listing.  The  following  table  is  an  alphabeti¬ 
cal  listing  of  all  current  mnemonics  and  the  corresponding  sec¬ 
tion  of  this  report  which  describes  them. 

SECTION  MNEMONIC 


F.l  ACQUISITION  PROBABILITY 

F.2  AGENT 

D.l  ALARM 

F.3  CEP  ERROR 

F.4  CEP  TLE 


2 


CHAINS 

COMPOUND  LINK 
CONVENTIONAL  LETHALITY 


Ok  «  >1  W  A 


CONTAMINATED  USAGE 
DECISION  RULES 

DEGRADATION 
DELIVERY  ERROR 
DEPLOYMENT 
DOSE  PARAMETERS 
EXPENDABLE 

FAILURE  RATE 

FATIGUE 

GO 

GRANULARITY 

HEADING 

INCOMING  FIRE 

INTERNAL  RECONSTITUTION  TIMES 

LINKS 

LOSSES 

MODE 

MOPP 

NAMES 

NUCLEAR  VUIMERABILITY 

OFFSET 

ORLINKS 

OUTPUT  OPTIONS 
PERSISTENCE 
RECONSTITUTION  EVENTS 
REINFORCEMENTS 
REPAIR 

REPLICATIONS 

REST 

ROUND 

SECONDARY  EXPLOSIVE 
SEEDS  (randoB  nuabar) 

SHIELDING 

STOP 

SUBCHAZNS 

SUBLBTHAL  DOSE  DEGRADATION 
THERMAL 

T.K.C.  (toxic  Mill  code) 

TLE 

TOXIC  DISPERSION  DATA 
TRACE  LINK  USAGE 


SECTION 


MNEMONIC 


11.  Events.  The  following  table  contains  the  mnemonics  from  the 
above  table  which  can  be  used  to  Insert  various  types  of  events 
Into  the  EVENT  TABLE  for  an  AURA  SIMULATION. 


SECTION  MNEMONIC 


F.l  ACQUISITION  PROBABILITY 

F.3  CEP  ERROR 

P.4  CEP  TLE 

F.5  DELIVERY  ERROR 

F.6  INCOMING  FIRE 

1.5  INTERNAL  RECONS.  TIMES 

D.5  LOSSES 

I . 8  RECONSTITUTION  EVENTS 

D . 6  REINFORCEMENTS 

F.7  ROUND 

F.8  TLE 

F.9  VOLLEY 

F.IO  WIND  DIRECTION 


C.  NAMES 

The  first  data  set  In  an  AURA  Input  stream  is  a  list  of 
names  to  be  used  for  assets  and  weapons.  Tills  block  may  be 
headed  by  a  NAMES  or  REPERTOIRE  card  and  muse  be  terminated 
(after  all  asset  and  weapon  names  have  been  listed)  by  one  END 
card.  A  group  of  asset  names  must  be  headed  by  a  ASSETS  card; 
weapon  names  must  be  headed  by  a  WEAPONS  card.  NOTE:  AN  END 
CARD  MAY  NOT  BE  PLACED  BETWEEN  THE  ASSET  AND  WEAPON  NAME  LISTS. 


Format:  (HR) 

ASSETS 

ASSET  NAMEl,  ALTERNATE  NAMEla,  ALTERNATE  NAMElb,  _ 

ASSET  NAME2,  ALTERNATE  NAME2a,  .... 

WEAPONS 

WEAPON  NAMEl,  ALTERNATE  NAMEll,  ALTERNATE  NAMEl j ,  .... 
WEAPON  NAME2,  ALTERNATE  NAME21,  .... 


Each  asset  and  weapon  must  have  at  least  one  unique  name. 
Alternate  names  are  used  to  associate  common  parameters  to  groups 
of  assets  or  weapons.  To  Invoke  certain  code  defaults,  the  fol¬ 
lowing  alternate  names  SHOULD  be  used: 

PERSONNEL  -  should  be  attached  to  each  personnel  asset 
CONVENTIONAL  -  should  be  attached  to  each  conventional  or 

mixed  conventional/toxic  weapon 


NUCLEAR  ■*  Should  be  attached  to  each  nuclear  weapon 

TOXIC  -  should  be  attached  to  each  toxic  or  mixed 

conventional/toxic  weapon 

Because  of  the  existence  of  special  characters  (see  section 
II.B.5),  it  is  recommended  that  all  names  begin  with  an 
alphanumeric  character. 


D.  Asset  Inputs 

The  following  data  sets  input  parameters  that  describe  the 
assets  (personnel  and  equipment)  of  a  unit. 

1.  ALARM.  This  option  identifies  chemical  alarms  and  Indicates 
threshold  for  activation  due  to  each  (toxic)  weapon.  (Currently, 
the  threshold  is  in  terms  of  dosage.) 

Format;  (Rl) 

ALARM 

asset  name  of  alarm  (as  defined  in  NAMES  input) 

WEAPON  NAMEl,  threshold  dosage  for  alarm  to  sound  (REAL) 
WEAPON  NAME2 ,  threshold  dosage  .... 


NOTES*  Toxic  dissemination  data  (UNIT  #4)  must  be  read  in  first 
to  allow  the  code  to  adjust  for  dose  normalization.  (See 
TOXIC  DISPERSION  DATA,  section  G.6.) 

Alarms  are  deployed  by  asset  name  like  any  other  equip¬ 
ment.  (See  DEPLOYMENT,  section  E.2.) 

Alarms  will  have  no  effect  (will  be  too  late)  if  person¬ 
nel  begin  to  MOPP-up  as  soon  as  round  arrives.  (See 
•ROUND*  option  under  MOPP,  section  E.3.) 


2.  CONTAMINATED  USAGE.  This  option  allows  designating  those 
items  of  equipment  which  may  be  used  when  contaminated,  along 
with  the  missions  (CHAINS)  in  which  this  usage  is  allowed. 

Format;  (Rl) 

CONTAMINATED  USAGE 

ASSET  NAME,  chain  numbers  (INTEGERS) 


NOTE;  If  chain  nvimbers  are  omitted,  all  chains  are  assumed. 


3.  EXPEMDABLE.  This  option  identifies  assets  that  are  expended 
as  they  are  used.  Two  fome  are  available:  Expenditure  by  time 
and  expenditure  by  repair  completion. 

Option  1,  expenditure  by  time: 

Format:  (Rl) 

EXPENDABLE 

ASSET  NAME,  rate  of  usage  by  time  (per  minute)  (REAL) 

Option  2,  expenditure  by  repair  completion: 

Format:  (HR) 

$ASS£T  NAME 

(NOTE:  For  assets  identified  as  expendeible  under  option  1,  the 
amount  that  is  assessed  as  expended  at  any  time  point  depends 
upon  the  amount  of  mission  time  spent  since  the  previous  update 
and  the  effectiveness  of  the  unit  during  that  time.  (Mission 
time  is  that  time  which  follows  a  reconstitution  and  extends 
until  Interrupted  by  a  lethality  event.)  Assets  identified  as 
expended  during  repair  or  decontcminatlon  activities  must  have 
HOMELINKS  which  appear  in  the  consuming  repair  subchains.  (See 
REPAIR,  section  D.7.)  Link  parameters  should  describe  amount 
needed  for  one  repair.  (See  LINKS,  section  B.6.) 


4.  FAILURE  RATE.  This  option  specifies  the  rate  at  which  assets 
undergo  spontaneous  (reliability^type)  failures.  Equipment  can 
fail  so  as  to  require  light,  medium,  or  infeasible  repair;  per¬ 
sonnel  can  only  have  dead  failures. 

Format;  (Rl) 

FAILURE  RATE 

ASSET  NAME,  mtbf,  fl,  fm 

where : 

mtbf  is  the  mean  time  (intrvl)  between  any  failures 
(REAL) 

fl  is  the  fraction  of  failures  requiring  light  repair 
(REAL) 

fm  is  the  fraction  requiring  medium  repair  (REAL) 

(NOTE:  If  fl  and  fm  are  not  specified,  all  failures  are  taken  as 
dead) 

Option:  Preload  pool  of  ongoing  repairs  at  time  0: 

Format:  (HR) 

PREFAIL, ON 

(NOTE:  When  PREFAIL  is  ON  (the  default  case) ,  light  and  medium 
repairs  are  prestarted,  simulating  an  ongoing  process  at  the  ini¬ 
tial  time  of  the  study.  This  option  avoids  having  too  many  items 
available  at  time  zero,  too  many  failing  afterwards,  and  a  delay 
in  the  repair  return  rate.) 

Option:  If  mtbf  is  entered  as  a  negative  number,  the  value  of 
mtbf  is  taken  as  a  probability  of  not  being  present  at 
time  0.  Requires  PREFAIL  option  ON. 


5.  LOSSES.  This  option  causes  prespecified  assets  to  disappear 
at  prespecified  times  in  an  encounter.  This  option  has  been 
used,  e.g.,  in  a  detailed  study  in  which  an  a  priori  decision  to 
remove  some  assets  at  a  point  in  the  encounter  was  part  of  the 
scenario. 

Format:  (Rl) 

LOSSES 

asset  name,  time,  number 

where : 

time  is  the  (clock)  time  of  removal  (REAL) 
number  is  the  number  of  assets  removed  (INTEGER) 


6.  REINFORCEMENTS.  The  opposite  of  LOSSES,  this  option  causes 
prespecified  assets  to  appear  at  prespecified  times  in  an 
encounter.  This  option  has  been  used,  e.g.,  in  a  detailed  study 
in  which  an  a  priori  decision  to  reinforce  some  assets  at  a  point 
in  the  encounter  was  part  of  the  scenario. 

Format:  (Rl) 

REINFORCEMENTS 

asset  name,  time,  number 

where : 

time  is  the  (clock)  time  of  reinforcement  (REAL) 
number  is  the  number  of  assets  added  (INTEGER) 


7.  REPAIR.  This  option  inputs  data  relative  to  the  repair  of 
damaged  or  failed  equipment.  Included  in  the  inputs  are  the  sub¬ 
tasks  (LINKS  or  SUBCHAINS)  needed  for  repair,  the  mean  time  and 
standard  deviation  in  the  mean  time  for  repair,  and  the  penalty 
(0.-  1.)  that  the  commander  would  be  willing  to  take  in  his 
immediate  mission  in  order  to  fix  the  item  if  the  need  for  the 
item  were  the  choke  point  in  the  mission.  AURA  also  uses  the 
penalty  value  to  help  prioritize  possible  repairs  at  various  lev¬ 
els. 


**************************************** 

The  REPAIR  ALGORITHM 

It  is  important  to  understand  the  ways  in  which  a  repair  can 
be  commissioned  and  role  played  by  the  penalty  value.  If  the 
unit's  future  capedjility  can  be  improved  by  repairing  an  item, 
the  commander  will  consider  adding  the  repair  of  the  item  to  his 
current  mission  and  optimize  the  allocation  of  assets  to  perform 
this  augmented  mission.  A  repair  ordered  this  way  is  called  a 
NEEDED  repair.  Note  that,  when  a  NEEDED  repair  is  being  done, 
the  reported  unit  effectiveness  may  be  determined  by  the  ability 
to  do  the  repair,  not  by  the  ability  to  do  the  actual  unit  mis¬ 
sion.  The  code  notes  the  difference  in  unit  effectiveness 
between  doing  only  its  actual  mission  versus  doing  the  repair  in 
addition  to  its  mission.  If  the  loss  in  mission  effectiveness  is 
less  than  the  penalty  value  specified,  then  the  repair  is  done  as 
part  of  the  mission:  its  influence  is  Included  in  the  effective¬ 
ness  of  the  unit.  Hence,  specifying  a  penalty  value  of  1.0 
implies  that  a  repair,  if  possible,  is  more  important  than  any¬ 
thing,  since  all  other  accomplishment  will  be  sacrificed,  if 
necessary,  to  repair  the  damaged  item.  Note,  moreover,  that  such 
a  penalty  is  never  required  for  an  essential  item,  since  mission 
accomplishment  when  the  item  is  damaged  is  already  low;  thus  the 
loss  in  effectiveness  during  repair  cannot  be  great. 


The  other  way  of  coaunlsslonlng  repair  work  is  on  an  as- 
avallable  (AS-AVL)  basis.  After  the  mission  (or  repair-augmented 
mission)  requirements  have  been  allocated,  the  commander  assigns 
any  remaining  repair  assets  to  do  any  repairs  that  can  be  done. 
These  repairs  are  considered  in  numerical  order  by  asset  ID 
number;  however,  the  top  priority  repair  level  is  considered  for 
every  asset  before  considering  lower  levels. 

Both  of  these  ways  of  implementing  repair  activity  are 
automatically  considered  by  AURA  if  the  REPAIR  option  is  used. 

A*************************************** 


As  implied  above,  repairs  can  be  specified  on  three  levels: 

0  =  contaminated,  1  =  light  repair  needed,  and  2  =  medium  repair 
needed.  It  is  assumed  that  light  or  medium  repair  can  be  applied 
to  the  specified  item  regardless  of  the  source  of  need  i.e. 
either  failure  or  combat  damage.  See  FAILURE  for  specification 
of  equipment  failures  and  Appendix  A  for  specification  of  combat 
damage  probabilities.  NOTE;  Repairable  combat  damage  requires 
BOTH  that  the  item  appear  as  a  repairable  under  this  mnemonic  AND 
that  the  item  has  exactly  three  kill  criteria  specified  in  the 
lethality  file. 

Format:  (Rl) 

REPAIR 
asset  name 

$cpl , Ivl 1 , pnlt 1 , mt 1 , sdl , xrpl , yrpl 
$cp2 , lvl2 , pnlt2 , . . . 

•  •  • 

where : 

cpI  is  the  Link  or  SUBCHAIN  needed  to  perform  level  I 
repair  on  the  named  asset 

Ivl I  is  the  level  of  repair  being  described  (INTEGER) 
pnltl  is  the  acceptable  mission  penalty  for  level  I 
repair  (REAL) 

mtl  is  the  mean  time  to  accomplish  level  I  repair 
(REAL) 

sdl  is  the  standard  deviation  in  mtl 

xrpl  and  yrpl  are  the  coordinates  of  the  location  at 
which  repair  of  this  item  at  this  level  would  take 
place 

NOTE:  If  an  asset  name  is  not  followed  by  repair  card(s) ,  a  warn¬ 
ing  is  printed.  The  code  then  assumes  that  the  user  wants  combat 
damage  levels  checked  and  tallied,  but  knows  that  there  is  no 
repair  available. 


Option;  GENERAL  REPAIR.  This  option  allows  specification  of 
general  repair  LINKS  or  SUBCHAINS,  i.e.  capabilities  which  must 
be  satisfied  ONCE  in  order  for  any  repairs  to  be  conducted. 

Format:  (Rl) 

GENERAL  REPAIR 
$gnrl  cp,  Ivl 

where : 

gnrl  cp  is  the  LINK  or  SUBCHAIN  needed  for  any  repair  at 
level  Ivl 

Ivl  is  the  level  for  which  gnrl  cp  applies 


Option:  MAXIMUM  NUMBER.  This  option  allows  specifying  the 
maximinn  niuaber  of  repairs  which  can  be  going  on  at  any  tine. 


Format:  (Rl) 

MAXIMUM  NUMBER,  maxrp 

where : 

maxrp  is  the  maximum  nvimber  of  repairs  that  can  be  ongo¬ 
ing  at  any  one  time  (INTEGER) .  Default, 
maxrp  »  50. 

Option:  NO  REPAIR.  This  option  allows  specifying  those  CHAINS 
in  which  no  repair  or  decontamination  is  allowed.  (See  FUNC¬ 
TIONAL  STRUCTURE,  section  B.6.)  NOTE:  CHAINS  input  must  precede 
REPAIR  input  if  this  option  is  used. 

Format:  (Rl) 

NO  REPAIR, nchl , nch2 , nch3 , . . . 

where: 

nchl  are  the  chains  which  do  not  allow  repair  or  decon¬ 
tamination. 


8.  SECONDARY  EXPLOSIVE.  This  option  allows  identifying  some 
assets  as  being  potential  sources  of  secondary  explosions  (i.e. 
being  detonated  by  an  Incoming  round  and  becoming  additional 
lethality  sources  themselves) .  To  use  this  option,  the  "explo¬ 
sive  potential"  is  given  a  name  (e.g.  SECONDARY)  which  appears 
in  the  NAMES  list  as  both  an  ASSET  and  a  WEAPON.  Similarly,  the 
name  appears  in  the  conventional  lethality  file  (see  Appendix  A) 
as  both  a  target  for  other  warheads,  where  data  describes  proba¬ 
bility  of  detonation,  and  as  a  warhead,  where  data  describes  the 
effect  of  a  detonation  against  all  other  targets  in  the  unit. 
This  option  is  used  to  associate  the  "explosive  potential”  with 
the  appropriate  (real)  assets  (e.g.  ammunition  stacks) . 

Format:  (HR) 

SECONDARY  EXPLOSIVE 

secondary  explosive  name,  associated  assetl,  .... 


E .  Deployment  Inputs 

The  following  data  sets  input  parameters  related  to  particu¬ 
lar  (geographical)  deployment  points.  Note  that  this  also 
includes  data  that  define  codes  for  any  status  that  is  location 
dependent  (like  MOPP  posture)  and  also  data  which  are  associated 
to  that  status  (such  as  degradation  due  to  MOPP  posture) . 

1.  DEGRADATION.  This  option  allows  the  user  to  associate  a  MOPP 
code  number  and  a  TOXIC  KILL  CRITERIA  (T.K.C.)  code  number  with 
a  performance  degradation  value.  When  the  code  is  evaluating  the 
effectiveness  of  individuals  in  doing  tasks,  it  degrades  the  con¬ 
tributions  according  to  the  current  MOPP  posture  and  the  T.K.C. 
of  each  deployment  point.  Thus,  the  degradation  of  a  job  due  to 
the  wearing  of  MOPP  is  input  via  the  T.K.C.  and  toxic  posture 
(and  alternate  toxic  posture,  if  used) .  (See  DEPLOYMENT,  section 
E.2  and  T.K.C.,  section  E.7.). 

Format:  (RO) 

DEGRADATION 

MOPP  code,  tkc,  dgf 

where : 

MOPP  code  is  defined  under  the  MOPP  option  (section  E.3) 
(INTEGER) 

tkc  is  defined  under  the  T.K.C.  option  (section  E.7) 
(INTEGER) 

dgf  is  the  degradation  factor  for  the  specified  MOPP 
posture  and  job  difficulty  (T.K.C.)  (REAL) 


2.  DEPLOYMENT.  This  option  Indicates  location,  nunber,  "kill 
criteria"  and  posture  of  assets.  A  supplementary  continuation 
line  may  be  used  to  Indicate  alternate  postures  and  tlmes-to- 
change-posture .  This  option  Is  also  used  to  locate  places  at 
which  DUMMYLINK  jobs  would  be  done.  (See  section  B.6.}  Each 
set  of  data  defines  a  TARGET  POINT. 

Format;  (Rl) 

DEPLOYMENT 

Name,  x,  y,  nmbr,  ckc,  nkc,  tkc,  cpst,  npst,  tpst 

where: 

name  Is  UNIQUE  name  of  asset  or  DUMMYLINK  name  at  tar¬ 
get  point 

X,  y  are  coordinates  In  UNIT  Coordinate  system  (REAL) 
nmbr  Is  the  nvunber  of  (Identical)  assets  at  the  point 
(REAL) 

ckc  Is  the  conventional  kill  criteria  code  (INTEGER) 
(See  APPENDIX  A,  Conventional  Lethality  Data.) 
nkc  is  the  nuclear  kill  criteria  (currently  has  no 
effect) 

tkc  Is  the  toxic  kill  criteria  code  (INTEGER)  (See, 
e.g. ,T.K.C.) 

cpst  Is  the  conventional  posture  code  (INTEGER) 
npst  Is  the  nuclear  posture  code  (INTEGER)  (See  SHIELD¬ 
ING) 

tpst  Is  the  toxic  posture  code  (INTEGER)  (See  MOPP) 

Option:  Alternate  posture: 

Format:  (RO) 

$cpst* , npst* , tlmel  or 
$tpst* , tlme2  or 

$cpst* , npst* , tlmel , tpst* , tlme2 

where : 

cpst*  Is  the  alternate  conventional  posture  (INTEGER) 
npst*  Is  the  alternate  nuclear  posture  (INTEGER) 
tlmel  Is  the  mean  time  (Intrvl)  required  to  change  to 
cpst*, npst*  (REAL) 

tpst*  Is  the  alternate  toxic  posture  (INTEGER) 
tlme2  Is  the  time  (Intrvl)  needed  to  change  to  tpst* 
(REAL) 

(NOTE;  If  cpst*, npst*  are  specified,  conventional  and 
nuclear  posture  change  begins  at  arrival  of  first  round. 
See  ALARM  for  start  of  toxic  posture  change.) 


Option:  MOPP  ALL.  This  option  provldos  a  short  cut  to  givs  all 
parsonnel  ths  sane  alternate  MOPP  posture  with  the  same  mean  time 
to  change. 

Format:  (Rl) 

MOPP  ALL,  tpst*,  tinea 

NOTES:  The  MOPP  ALL  card  can  be  inserted  anywhere  in  the  deploy¬ 
ment  input  set.  If  used,  it  supercedes  any  individual  alternate 
MOPP  postures. 

Option:  \OFFSET.  This  option  allows  adding  specified  values  to 
the  X  and  y  coordinates  of  all  deployment  points  which  follow  in 
the  runstream.  This  option  provides  an  easy  method  of  displacing 
a  section  of  a  deployment.  As  denoted  by  the  leading  backslash, 
this  is  an  imbedded  procedure  command.  (See  section  II. B. 5.) 

Format:  (Rl) 

\OFFSET,  x-displacement,  y-displacement  (REAL) 

NOTE:  The  offset  generated  by  this  command  is  ADDITIVE  to  the 
offset  generated  by  the  OFFSET  command  or  by  the  OFFSET  card  in 
the  execute  stream.  (See  sections  II. A  and  II. E. 4.) 


3.  MOPP.  This  option  allows  the  user  to  define  the  toxic  pos¬ 
ture  (MOPP)  codes  (used  In  DEPLOYMENT  for  initial  and  alternate 
toxic  posture)  and  specify  a  transmission  factor  for  each.  The 
transmission  factor  is  used  to  reduce  the  dosage  received  by  an 
Individual  or  contamination  received  by  a  piece  of  equipment  for 
an  asset  in  the  specified  toxic  posture.  This  command  is  also 
used  to  set  a  number  of  options  dealing  with  the  assumption  of 
alternate  MOPP  posture. 

Format:  (Rl) 

MOPP 

Verbal  description  (<13  letters) ,  tcode,  tf 

where : 

tcode  is  the  toxic  code  number  (INTEGER) 
tf  is  the  fraction  of  agent  still  received  in  posture 
(REAL) 

(NOTE:  Codes  0-4  default  to  "OPEN",  "MOPP  I",  "MOPP  II",  etc., 
with  transmissions  decreasing  from  1.0  to  0.0) 

Options:  These  set  various  MOPP  change  parameters: 

Format:  (Rl) 

ALL  CLEAR  YES,  or  ALL  CLEAR  NO.  This  option  automati¬ 
cally  returns  unit  individuals  to  initial  MOPP  posture 
when  the  last  contaminant  evaporates  or  is  removed  by 
decontamination . 

Default  is  ALL  CLEAR  YES. 

PROXIMITY,  dlst  (REAL) .  This  option  allows  specifying 
the  (X  and  y)  distance  from  a  warhead  within  which  an 
asset  must  be  in  order  to  "feel  threatened"  by  an  incom¬ 
ing  round  and  change  MOPP  posture.  (See  ROUND  YES, 
immediately  below.) 

Default,  dlst  »  Infinity. 

RECONSTITUTION  YES,  or  RECONSTITUTION  NO.  This  option 
causes  all  personnel  to  assume  alternate  MOPP  posture 
during  a  reconstitution  while  contaminant  is  present. 
Default  is  RECONSTITUTION  NO. 

RECOVERY  TIME,  trcvr  (REAL) .  This  option  Inputs  the 
time  (Intrvl)  needed  to  realize  that  contamination  is  no 
longer  present  and  to  reassume  initial  MOPP  posture. 
Default,  trcvr  =  30. 

ROUND  YES,  tfalse  (REAL)  or  ROUND  NO.  This  option  con¬ 
trols  whether  individuals  assume  alternate  MOPP  posture 
upon  any  Incoming  round.  If  ROUND  YES,  the  value  tfalse 
is  the  time  (Intrvl)  needed  to  recognize  that  none  of 
the  incoming  rounds  were  toxic  and  to  return  to  initial 
MOPP  posture. 


Default,  ROUND  YES,  t false  =  10. 


TIME  SPREAD,  sigma  (REAL) .  This  option  inputs  the  frac¬ 
tional  standard  deviation  in  time  needed  to  change  MOPP 
posture. 

Default,  sigma  «  0.2. 


4.  OFFSET.  This  option  reads  x  and  y  offset  values  which  are 
added  to  the  x  and  y  coordinates  of  every  deployment  point  before 
the  analysis  commences.  This  allows  the  user  to  use  one  generic 
deployment  of  a  unit,  centered  around  0.,0.,  and  displace  the 
entire  deployment  to  specific  (battlefield)  locations. 

Format:  (RO) 

OFFSET 

x-of fset  (REAL) ,  y-offset  (REAL)  in  UNIT  coordinate  sys¬ 
tem 

NOTE:  Offsets  can  also  be  input  via  the  computer's  normal  input 

channel  as  part  of  program  execution.  In  case  of  conflict, 
offsets  input  via  the  execution  stream  take  precedence.  (See 
EXECUTION,  section  A.)  The  offset  input  via  this  command  or  via 
the  execution  stream  is  ADDITIVE  to  any  offset  input  via  the 
\0FFSET  option  under  DEPLOYMENT.  (See  section  II. E. 2.) 


5.  REST.  This  option  specifies  the  places  to  which  personnel 
assets  deploy  when  assigned  to  rest.  (See  FATIGUE.)  If  no  rest 
location  is  specified  for  an  asset,  it  is  assumed  that  the  asset 
will  rest  at  his  duty  station. 

Format:  (Rl) 

ASSET  NAME,  X,  y,  ckc,  nkc,  tkc,  cpst,  npst,  tpst 

Option:  Alternate  postures: 

Format:  (RO) 

$cpst*,npst*,timel  or 
$tpst*,time2  or 

$cpst* , npst* , t imel , tpst* , t ime2 

(NOTE:  See  DEPLOYMENT  for  definition  of  data.  This  input  is 
identical  to  DEPLOYMENT  except  1)  nmbr  is  omitted  and  2)  ASSET 
NAME  need  not  be  unique.) 


6.  SHIELDING.  This  option  allows  the  user  to  define  nuclear 
posture  code  numbers.  Shielding  associates  a  verbal  description 
and  a  transmission  matrix  with  the  code  number. 

Format:  (Rl) 

SHIELDING 

verbal  description,  npst,  trnsl,  trns2,  trns3,  trns4 

where : 

npst  Is  the  code  number  (INTEGER,  between  4-61) 
and  the  transmission  factors  are  defined  by: 

trnsl  ®  (n,n*) 

tms2  =  (g,n*)  (usually  =  0) 
trns3  **  (n,g*) 
trns4  *  (g^g*) 

where : 

n  indicates  neutron 

g  indicates  gamma,  and 

(a,b*)  Indicates  dosage  of  type  b  in  the  posture 
due  to  an  incident  dosage  of  type  a. 

NOTES:  If  only  trnsl  is  given,  it  is  used  for  trnsl  and  trns4; 

trns2  and  trns3  are  set  «  0.  Nuclear  posture  codes  1,  2,  and  3 

are  reserved  for  OPEN,  OPEN-BUT-THERMALLY-SHIELDED,  and  FOXHOLE, 
respectively.  No  vehicle  can  be  associated  with  posture 
codes  1-3.  Codes  4  and  5  default  to  APC  and  TANK;  however,  the 
user  must  associate  any  vehicular  blast  protection.  (See  follow¬ 
ing  option.) 

Option:  An  asset  (usually  a  vehicle)  can  be  associated  to 
nuclear  posture  codes  4  through  61.  Doing  so  gives  an  individual 
in  the  posture  the  same  blast  criteria  as  the  associated  vehicle. 

Format:  (Rl) 

$associated  asset  name 


7.  T.K.C.  (TOXIC  KILL  CRITERIA).  This  option  allows  the  user 
to  define  his  toxic  kill  criteria  code  numbers.  T.K.C.  associ¬ 
ates  with  the  code  number  a  verbal  description  and  a  chemical 
dosage  multiplier  (used  to  simulate  higher  (or  lower)  than  normal 
ratio  of  dose/ dosage,  as  would  be  acquired  by  a  person  whose  task 
required  a  higher  (or  lower)  than  normal  breathing  rate) .  This 
Input  also  allows  specifying  heat  stress  parameters,  which  are 
also  job  dependent.  The  effect  of  the  TOXIC  KILL  CRITERION  code 
number  In  general,  and  this  option  In  particular.  Is  to  allow  the 
user  to  Indicate  deployment  points  at  which  a  difficult  (or  easy) 
job  Is  being  done.  Any  Individual  assigned  to  that  deployment 
point  Inherits  the  difficulties  of  the  job.  (See  also  DEGRADA¬ 
TION,  section  E.l.) 

Format:  (Rl) 

T.K.C. 

Verbal  description  (<13  letters) ,  tkc,  dm,  peas,  tlag, 
tau 

where : 

tkc  Is  the  toxic  kill  criteria  code  number  (INTEGER) 

dm  Is  the  dosage  multiplier (REAL) 

peas  Is  the  prob.  of  heat  stress  In  alt.  MOPP  (REAL) 

tlag  Is  the  heat  stress  lag  time  (Intrvl)  (REAL) 

tau  Is  the  characteristic  prob.  growth  time  (intrvl) 

(REAL) 

(NOTE:  peas,  tlag  and  tau  are  optional) 


F.  weapon  Inputs 

The  following  data  sets  input  parameters  relating  to  weapon 
delivery  system  performance  and  weapon  arrival  events. 

1.  ACQUISITION  PROBABILITY.  This  option  inputs  a  single  proba¬ 
bility  number  which  represents  the  probability  that  the  unit  has 
been  acquired.  This  option  also  allows  a  change  in  probedaility 
via  a  change  event.  A  random  number  is  drawn  against  the  current 
probability  value  and  the  acquisition  status  redetermined  at  the 
beginning  of  every  replication  and  upon  every  change  event. 
Before  every  lethality  event,  acquisition  status  is  checked:  if 

in  a  non-acquired  state,  lethality  events  are  skipped. 

Format:  (HO) 

ACQUISITION  PROBABILITY 
pacqr 

where : 

pacqr  is  the  target  acquisition  probability 

Option:  This  option  can  be  used  to  input  an  ACQUISITION  PROBA¬ 
BILITY  change  event.  This  allows  the  user  to  simulate  a  point  in 
time  at  which  the  probability  of  target  acquisition  changes,  as 
would  be  caused  by  unit  movement.  It  also  causes  a  new  random 
number  to  be  drawn.  Thus,  to  model  Independent  attacks  on  parts 
of  a  separated  unit,  use  of  this  option  will  cause  acquisition 
probabilities  to  be  uncorrelated. 

Format:  (RO) 

time,  pacqr 

where : 

time  is  the  (clock)  time  at  which  the  change  in  error 
occurs  (REAL) 


2.  AGENT.  This  option  associates  a  toxic  agent  type  with  a 
specific  weapon. 

Format:  (HR) 

AGENT 

weapon  name ,  atyp 

where : 

atyp  is  G,  V,  or  H.  Default,  atyp  =  G. 


3.  CEP  ERROR.  This  option  reads  delivery  errors  expressed  In 
circular  error  probable  (CEP) .  (CEP  is  that  radius  within  which 
one  half  of  the  rounds  are  expected  to  fall.) 

Format:  (Rl) 

CEP  ERROR 

weapon  name,  indcep,  cor cep,  hob 

where: 

indcep  is  the  independent  circular  error  (REAL) 
corcep  is  the  volley-correlated  circular  error  (REAL) 
hob  is  the  standard  deviation  in  helght-of-burst 
(REAL) 

IMPORTANT  NOTE:  Values  of  errors  >  0  result  in  errors  being 

drawn  from  a  Gaussian  distribution  having  a  shape  parameter 
derived  from  the  input  error  value.  Values  <  0  result  in  errors 
being  drawn  from  a  uniform  distribution  having  a  range  parameter 
derived  from  the  input  error  value.  Positive  and  negative  values 
may  be  mixed  on  the  same  card. 

Option:  This  option  can  be  used  to  input  a  CEP  ERROR  change 
event.  This  allows  the  user  to  simulate  a  point  in  time  at  which 
the  error  in  incoming  fire  changes,  as  would  be  caused  by  unit 
movement . 

Format:  (Rl) 

CEP  ERROR 

weapon  name,  time,  indcep,  corcep,  hob 

where: 

time  is  the  (clock)  time  at  which  the  change  ia  error 
occurs  (REAL) 


4.  CEP  TLE.  This  option  reads  target  location  errors  expressed 
in  circular  error  probable  (CEP) . 

Format:  (RO) 

CEP  TLE 
tlecep 

where : 

tlecep  is  the  target  location  error,  expressed  as  a  cir¬ 
cular  error  probable  (REAL) 

NOTE:  See  IMPORTANT  NOTE  under  CEP  ERROR  for  choice  of  distribu¬ 

tions. 

Option:  This  option  can  be  used  to  input  a  CEP  TLE  change  event. 
This  allows  the  user  to  simulate  a  point  in  time  at  which  the 
error  in  target  location  changes,  as  would  be  caused  by  iinit 
movement . 

Format:  (RO) 

CEP  TLE 
time,  tlecep 

where : 

time  is  the  (clock)  time  at  which  the  change  in  error 
occurs  (REAL) 


5.  DELIVERY  ERROR.  This  option  Inputs  weapon  delivery  errors  as 
standard  deviations  In  RANGE  and  DEFLECTION. 

Format:  (Rl) 

DELIVERY  ERROR 

weapon  name,  rind,  rcor,  dlnd,  door,  hob 

where : 

rind  Is  the  Independent  error  In  range  (REAL) 
rcor  Is  the  volley-correlated  error  In  range  (REAL) 
dlnd  Is  the  Independent  error  In  deflection  (REAL) 
dcor  Is  the  volley-correlated  error  In  deflection 
(REAL) 

hob  Is  the  error  in  height-of-burst  (REAL) 

NOTE:  See  IMPORTANT  NOTE  under  CEP  ERROR  for  choice  of  distribu¬ 

tions. 

Option:  This  option  can  be  used  to  Input  a  DELIVERY  ERROR  change 
event.  This  allows  the  user  to  simulate  a  point  In  time  at  which 
the  error  In  weapon  delivery  changes,  as  might  be  caused  by  unit 
movement . 

Format:  (Rl) 

DELIVERY  ERROR 

weapon  name,  time,  rind,  rcor,  dlnd,  dcor,  hob 

where : 

time  Is  the  (clock)  time  at  which  the  change  takes 
place  (REAL) 


6.  INCOMING  FIRE  DIRECTION.  This  option  orients  the  incoming 
fire  (RANGE)  direction  with  respect  to  the  UNIT  Coordinate  sys¬ 
tem.  See  discussion  of  coordinate  systems  in  section  B.8. 

Format:  (RO) 

INCOMING  FIRE  DIRECTION 
incang 

where : 

incang  is  the  angle  (degrees)  from  the  UNIT  x  direction 
to  the  RANGE  direction  (INTEGER,  positive  if 
counter-clockwise  ) . 

Default,  incang  =  0. 

Option:  Incoming  fire  direction  change  event. 

Format:  (RO) 

INCOMING  FIRE  DIRECTION 
time,  incang 

where : 

time  is  the  (clock)  time  at  which  the  incoming  fire 
direction  changes  (REAL) . 

Option:  The  incoming  fire  direction  can  also  be  specified  as  a 
range  of  directions,  in  which  case  the  code  will  randomly  select 
a  new  direction  within  the  specified  range  for  each  replication. 

Format:  (RO) 

INCOMING  FIRE  DIRECTION 
incangl ,  incang2 

where : 

incangl  and  lncang2  are  the  angles  between  which  the 
incoming  fire  directions  will  lie  (INTEGERS) 

Option:  Incoming  fire  direction  change  event,  specified  as  a 
range . 

Format;  (RO) 

INCOMING  FIRE  DIRECTION 
time,  incangl,  incang2 


7.  ROUND.  This  option  inputs  the  parameters  necessary  to 
specify  an  attack  by  a  single  round. 


Format:  (Rl) 

ROUND 

weapon  name,  time,  apx,  apy,  apz 

where : 

time  is  the  (clock)  time-of-arrival  of  the  round  (REAL) 
apx  is  the  intended  x-coordinate  (UNIT  Coordinate  sys¬ 
tem)  (REAL) 

apy  is  the  intended  y-coordinate  (UNIT  Coordinate  sys¬ 
tem)  (REAL) 

apz  is  the  intended  height-of-burst  (REAL) 


8.  TLE.  This  option  reads  target  location  errors  expressed  as 
standard  deviations. 

Format;  (RO) 

TLE 

tlex,  tley 

where ; 

tlex  is  the  x-coordinate  of  the  target  location  error 
(REAL) 

tley  is  the  y-coordinate  of  the  target  location  error 
(REAL) 

NOTE:  See  IMPORTANT  NOTE  under  CEP  ERROR  for  choice  of  distribu¬ 
tions. 

Option:  This  option  can  be  used  to  input  a  TLE  change  event. 
This  allows  the  user  to  simulate  a  point  in  time  at  which  the 
error  in  target  location  changes,  as  would  be  caused  by  unit 
movement . 

Format:  (RO) 

TLE 

time,  tlex,  tley 

where ; 

time  is  the  (clock)  time  at  which  the  change  in  error 
occurs  (REAL) 
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9.  VOLLEY.  This  Option  inputs  parameters  necessary  to  specify 
an  attack  by  a  volley  of  weapons.  The  Intended  pattern  is 
assximed  to  be  a  line  of  the  specified  width  and  at  the  specified 
angle  with  respect  to  the  INCOMING  FIRE  direction.  A  cluster- 
type  munition  (scatter  about  a  single  point)  can  be  modeled  by 
specifying  a  volley  pattern  width  of  0. 

Format:  (Rl) 

VOLLEY 

weapon  name,  time,  papx,  papy,  papz,  nrd,  ang,  width 

where: 

time  is  the  (clock)  time  of  the  attack  (REAL) 
papx  is  the  intended  x-coord.  of  the  pattern  midpoint 
(REAL) 

papy  is  the  intended  y-coord.  of  the  pattern  midpoint 
(REAL) 

papz  is  the  Intended  helght-of-burst  of  the  rounds 
(REAL) 

nrd  is  the  nxmber  of  rounds  in  the  volley  (INTEGER) 
ang  is  the  angle  (degrees)  of  the  pattern  line  with 
respect  to  the  Incoming  direction.  (REAL) 
width  is  the  width  of  the  pattern  line  (REAL) 

Option:  This  option,  used  after  a  normal  volley  data  card 
(above) ,  creates  multiple  volleys  with  the  specified  time  between 
volleys,  each  one  "stepped"  in  the  specified  direction  by  the 
specified  distance.  This  option  allows  easy  modeling  of  a  moving 
barrage . 

Format: 

$  nvol,  dtm,  dir,  dis 

where : 

nvol  is  the  nxunber  of  ADDITIONAL  volleys  (INTEGER) 
dtm  is  the  tlme-between-volleys  (intrvl)  (REAL) 
dir  is  the  angle  (degrees)  of  movement  of  the  Intended 
pattern  midpoint  measured  counter-clockwise  from 
the  X  direction  (in  the  UNIT  Coordinate  system) 
(REAL) 

dis  is  the  distance  of  movement  (REAL) 


10.  WIND  DIRECTION.  This  option  orients  the  wind  (RANGE)  direc¬ 
tion  with  respect  to  the  UNIT  Coordinate  system.  See  discussion 
of  coordinate  systems  in  section  B.8. 


Format:  (RO) 

WIND  DIRECTION 
windang 

where: 

windang  is  the  angle  from  the  UNIT  x  direction  to  the 
RANGE  direction  (INTEGER,  positive  if  counter¬ 
clockwise  ) . 

Default,  windang  «  0. 

Option:  Wind  direction  change  event. 

Format:  (RO) 

WIND  DIRECTION 
time,  windang 

where: 

time  is  the  (clock)  time  at  which  the  wind  direction 
changes  (REAL) . 

Option:  The  wind  direction  can  also  be  specified  as  a  range  of 
angles,  in  which  case  a  new  wind  direction  is  randomly  selected 
within  the  specified  range  for  each  replication. 


Format: 


where : 


(RO) 

WIND  DIRECTION 
windangl,  windang! 


windangl  and  windang!  are  the  angles  within  which  the 
wind  direction  will  lie  (INTEGERS) 

Option:  Wind  direction  change  event,  specified  as  a  range. 

Format:  (RO) 

WIND  DIRECTION 

time,  windangl,  windang! 


11.  YIELD.  This  option  inputs  the  yield  of  nuclear  weapons. 

Format:  (Rl) 

weapon  name,  yldl,  yld2 

where: 

yldl  is  the  blast  and  thermal  yield  in  kt  (REAL) 
yld2  is  the  effective  radiative  and  emp  yield  in  kt 
(REAL) 

NOTE:  If  only  yldl  is  given,  it  is  used  for  both  yldl  and  yld2. 


G.  Weapon  Effects 

The  following  data  sets  input  parameters  relating  to  the 
effects  of  weapons  on  assets. 

1.  CONVENTIONAL  LETHALITY.  This  Option  causes  the  AURA  code  to 
read  a  conventional  lethality  data  file  via  input  unit  #2.  No 
further  data  is  needed.  (See  Appendix  A  for  the  format  of  the 
conventional  lethality  data  file.) 

Format:  (  not  applicable  ) 

CONVENTIONAL  LETHALITY  DATA 


2.  DOSE  PARAMETERS.  This  option  allows  changing  various  parame¬ 
ters  which  control  the  personnel-response-to-dosage  algorithms 
and  the  output  report  of  dosages. 

Format:  (all  Rl) 

DOSE  PARAMETERS 
options 

Option:  Set  values  for  dosage  "bins"  for  dosage  distribution 
report  in  output. 

Format:  (Rl) 

DOSE  BINS, bl, b2,b3,b4, .. .bio 

where: 

bl  is  the  center  value  of  the  first  bin  etc. 

Defaults:  Appropriate  for  nuclear  and  toxic. 

NOTES:  There  must  be  10  increasing  bin  values.  Do  not  input 
bl  =  0.  bio  may  -  MAX  DOSE,  but  may  not  exceed  it. 

Option:  Set  maximum  dosage  to  be  considered  as  Instant  casualty 

Format:  (Rl) 

MAX  DOSE,  maximxim  dosage  value  (REAL) 

Defaults:  »  200.  Gy  (Nuclear) ;  =  inf.  (Toxic) 

Option:  Set  minimum  dosage  to  be  considered  for  lethality,  ETI. 

Format:  (Rl) 

MIN  DOSE,  minimum  dosage  value  (REAL) 

Defaults:  «  4.5  Gy  (Nuclear);  «  1.0  (Toxic) 

Option:  Turn  on/off  ETI,  PCI,  and  dose-related  degradation  of 
performance  algorithms.  Not  of  general  usefulness. 

Format:  (Rl) 

NUCNTL,  control  code  number  (INTEGER) 

(See  INFO  source  file  (BRL)  for  particulars.) 

Default:  All  algorithms  operant. 

Option:  Set  the  level  of  dosage  Induced  performance  degradation 
below  which  an  asset  may  be  replaced  in  his  own  homelink  by  a 
substitute.  (See  HOMELINK  in  section  B.6.) 

Format:  (Rl) 

SICKLV,  performance  level  (REAL) 

Default:  sickness  performance  level  =  0.75 


3.  NUCLEAR  VULNERABILITY.  This  option  causes  the  AURA  code  to 
read  a  nuclear  vulnerability  data  file  via  input  vinit  #3.  No 
further  data  is  needed.  (See  Appendix  A  for  the  format  of  the 
nuclear  vulnerability  data  file.) 

Format:  (  not  applicable  ) 

NUCLEAR  VULNERABILITY  DATA 


4.  PERSISTENCE.  This  Option  allows  changing  the  persistence 
time  for  chemical  agents  on  specified  assets  from  the  standard 
(uniform)  persistence  time  produced  by  the  toxic  dissemination 
code  (NUSSEII) .  The  change  is  affected  by  specifying  the  ratio 
of  time-to-evaporat e/diffuse  from  the  asset  to  time-to-evaporate 
as  output  by  NUSSEII. 

Format:  (Rl) 

PERSISTENCE 
weapon  namel 
assetl,  frcll 
asset2 ,  f rcl2 


weapon  name2 
asset l,frc21 
etc. 

where : 

frcIJ  is  the  ratio  of  evap  time  for  agent  from  weapon  I 
on  the  asset  J  to  the  NUSSEII  output  evap  time. 

NOTE:  TOXIC  DISPERSION  command  must  precede  this  option. 


5.  THERMAL.  This  option  allows  the  user  to  specify  the  atmos¬ 
pheric  thermal  transmissivity  and  the  type  of  uniform  being  worn. 
These  parameters  affect  the  calculation  of  thermal  casualties. 

Format:  (all  HR) 

THERMAL 

options 

Option:  Thermal  transmissivity 
Format:  (HR) 

ATMOSPHERE,  quality 

where: 

quality  must  be  GOOD,  AVERAGE,  or  POOR 
Default  Is  AVERAGE 

Option:  Type  of  uniform 
Format:  (HR) 

UNIFORM,  type 

where: 

type  must  be  SUMMER  or  WINTER 

Default  Is  SUMMER  for  Initial  posture,  WINTER  for  alter¬ 
nate  MOPP  posture 


6.  TOXIC  DISPERSION.  This  option  causes  the  AURA  code  to  read  a 
toxic  dispersion  data  file  via  Input  unit  #4.  No  further  data  Is 
needed.  (See  Appendix  A  for  the  format  of  the  toxic  dispersion 
data  file.) 

Format:  (  not  applicable  } 

TOXIC  DISPERSION  DATA 


H.  Unit  Function  inputs 


The  following  data  sets  Input  parameters  which  model  the 
functional  structure  of  a  unit.  (See  FUNCTIONAL  STRUCTURE,  sec¬ 
tion  B.6. ) . 

1.  CHAINS.  This  option  allows  the  (overall)  "ANDing"  together 
of  sets  of  operations  (called  SEGMENTS)  to  satisfy  the  require¬ 
ments  of  missions,  one  chain  per  mission.  Segments  may  be  any 
previously  defined  LINKS,  SUBCHAINS,  ORLINKS  or  COMPOUND  LINKS. 

Format;  (HR) 

sgll,  sgl2,  sgl3,  sgl4,  .... 
sg21,  sg22,  sg23,  ..... 
etc. 

where : 

sglJ  is  the  Jth  segment  in  chain  I. 

Option:  A  continuation  line  which  begins  with  the  word  TIME  (may 
be  abbreviated  to  T)  is  Interpreted  as  a  set  of  (clock)  times 
during  which  the  preceding  chain  is  operant.  Thus  the  available 
missions  for  a  unit  may  change  during  the  encounter. 

Format;  (Rl) 

$T,  strl,  stpl,  str2,  stp2,  .... 


strl  is  the  (clock)  time  that  a  chain  becomes  operant 
stpl  is  the  corresponding  time  that  it  ceases  to  be 
available 


where : 


2.  COMPOUND  LINKS.  This  option  Inputs  data  for  compound  links 
(CPLINKs) ,  i.e.  functional  structures  which  are  weighted  summa¬ 
tions  of  parts  (called  CPPARTS) .  A  CPPART  may  be  a  simple  LINK, 
a  SUBCHAIN  or  an  ORLINK.  NOTE:  A  COMPOUND  LINK  name  MUST  begin 
with  the  1  character. 

Format:  (Rl) 

COMPOUND  LINK 

compound  link  namel  (must  begin  with  ! ) 
cppartll,  wtll 
cppartl2,  wtl2 

•  •  •  • 

compound  link  name2 
cppart21,  wt21 

•  •  •  • 

where : 

cppartlJ  is  the  name  of  the  jth  part  of  CPLINK 
wtlJ  is  the  weight  of  cppart  IJ 

NOTE:  The  weights  for  any  CPLINK  usually  sum  to  1.  A  warning 
message  is  printed  if  summation  is  not  1.,  but  run  will  proceed. 


3.  FATIGUE.  This  option  allows  the  user  to  specify  that  dif¬ 
ferent  jobs  (LINKS)  may  be  more  or  less  demanding  than  others, 
both  in  terms  of  the  need  for  personnel  to  be  rested  and  the 
drain  upon  personnel  who  are  engaged  in  the  job. 

Format:  (Rl) 

FATIGUE 

link  name,  rfr,  rd 


rfr  is  the  relative  fatigue  rate  (REAL) 

rd  is  the  relative  demand- for-stored-rest  (REAL) 


where : 


4.  LZMKS.  This  option  Inputs  data  on  basic  subtasks  Including: 

1)  relationships  between  number  of  effective  assets  allocated  to 
svibtask  and  effectiveness  of  subtask  performance  (see  figure  1) , 

2)  limitations  on  numbers  of  ENTITIES  (l.e.  actual  number  of 
personnel  or  Items  of  equipment  assigned,  regardless  of  relative 
worth  of  each  entity)  which  may  be  assigned  to  task  and  3}  sub¬ 
stitutes,  l.e. assets  which  may  be  assigned  to  task  In  addition  to 
HOMELINK  asset.  (See  HOMELINK,  section  A. 6.) 

Format:  (Rl) 

LINKS 

link  name,  caplOO,  maxeff,  entmax 

where : 

link  name  Is  any  allowed  name.  If  link  name  Is  the  name 
of  an  asset,  this  entry  defines  the  HOMELINK  for 
the  asset 

caplOO  Is  niimber  of  eff.  assets  needed  for  maximum 
effectiveness  (REAL) 

maxeff  Is  maximum  effectiveness  IN  PERCENT  (INTEGER) 
Default,  maxeff  «  100 

entmax  Is  maximum  number  of  Items  that  may  be  assigned 
to  link. 

entmax  Is  taken  as  an  absolute  value  unless  an 
ASSOCIATED  LINK  Is  defined.  In  which  case  entmax 
Is  taken  as  the  number  per  Item  In  the  ASSOCIATED 
LINK  (See  ASSOCIATED  LINK  immediately  below.) 
(REAL)  Default,  entmax  »  unlimited. 

Option:  Specify  lower  bounds  on  link  effectiveness 
Format :  (R6)  (^1) 

$tY\capO,  mlneff 

where : 

capo  is  number  of  eff.  assets  below  which  effectiveness 
Is  mlnlmvim  (REAL)  Default,  capO  »  0. 
mlneff  Is  minimum  effectiveness  IN  PERCENT  (INTEGER) 
Default,  mlneff  =  0 

Option:  Specify  an  ASSOCIATED  LINK.  An  ASSOCIATED  LINK  is 

another  subtask  whose  potential  fulfillment  controls  the  entitles 
assignable  to  the  current  svibtask.  For  example,  If  there  can  be 
only  two  operators  per  system  X,  this  option  can  be  used  as  fol¬ 
lows;  System  X  would  be  defined  as  a  normal  link.  The  operator 
link  would  be  defined  with  2.  for  the  value  of  entmax  on  card  1 
and  System  X  as  the  associated  link. 

Format ; 

$A,  associated  link  name 

Option;  Substitutes.  Substitutes  are  defined  by  sets  of  three 
cards . 


Format:  (HR)/(R1)/(R1) 

$subnml,  subnm2,  subnnS,  ..... 

$E,  effl,  eff2,  eff3,  _ 

$T,  timl,  tlm2,  tim3,  .... 

where : 

subnml  is  the  name  of  the  Ith  substitute  (need  not  be  a 
unique  name) 

effl  is  the  effectiveness  of  the  Ith  svibstitute  (rela¬ 
tive  to  normal  assets  implied  in  specifying 
caplOO)  (REAL) 

timl  is  the  time  (intrvl)  needed  for  the  Ith  asset  to 
sxibstitute 

NOTE:  It  is  essential  that  each  substitute  card  be  followed  by 
an  effectiveness  card  and  a  time  card.  If  the  number  of  substi¬ 
tutes  exceeds  the  capacity  of  the  first  substitute  card,  addi¬ 
tional  substitutes  may  be  specified  by  following  the  first  set  of 
three  cards  with  other  sets. 


5.  0RLINK8.  This  option  inputs  data  to  define  functional  struc¬ 
tures  (called  ORLINKS)  that  represent  mutually  exclusive  choices 
for  the  accomplishment  of  part  of  a  mission.  The  choices,  called 
"branches”,  may  be  SUBCHAINS  or  simple  LINKS.  NOTE:  An  ORLINK 
name  must  be  of  the  form  "+number",  where  the  number  lies  between 
1  and  23. 

Format:  (HR) 

ORLINKS 

or link  name,  brl,  br2,  br3,  .... 

where : 


or  link  name  is  of  the  fo3nn  +number  (e.g.  +4) 

brl,  the  Ith  branch,  is  the  name  of  a  link  or  subchain 


6.  SUBCHAINS.  This  option  inputs  data  to  define  functional 
structures  (called  SUBCHAINS)  that  represent  sets  of  subtasks 
that  must  work  together  to  accomplish  part  of  a  mission.  NOTE: 
A  SUBCHAIN  name  must  be  of  the  form  "*number",  where  the  number 
lies  between  1  and  26. 

Format:  (HR) 

SUBCHAINS 

sxibchain  name,  Inkl,  lnk2,  lnk3,  .... 


where : 


subchain  name  is  of  the  form  *number  (e.g.  *4) 
Inkl  is  the  name  of  the  Ith  link  in  the  subchain 


THRESHOLD  OPTIMUM 

EFFECTIVE  ASSETS  ALLOCATED 


1.  General  Fom  of  a  Link  Effectiveness  Curve 


7.  SUBLETHAL  DOSE  DEGRADATION.  This  option  associates  specified 
LINKS  with  particular  dose-time  degradation  sets  which  can  be 
used,  e.g.,  to  degrade  dosed  individuals  assigned  to  physically 
demanding  jobs  more  severely  than  those  in  cognitive  jobs.  Two 
degradation  sets  are  built  into  AURA  which  describe:  a  gunner 
(degradation  set  number  0) ,  typical  of  most  jobs  and  an  ammuni¬ 
tion  loader  (degradation  set  number  -1) ,  typical  of  a  physically 
demanding  job.  The  default  for  all  LINKS  (without  use  of  this 
option)  is  degradation  set  0. 


Format:  (Rl) 

SUBLETHAL  DOSE  DEGRADATION 
link  name,  code  number  (INTEGER) 

Option:  Read  new  degradation  data  from  input  unit  #11.  This 
option  also  allows  reading  additional  degradation  sets  to  which 
new  degradation  set  numbers  (  l  -  5  )  are  given.  These  sets  are 
then  available  for  association  with  specific  LINKS.  NOTE;  For¬ 
mat  for  the  data  on  unit  #11  is  given  in  Appendix  B. 


Format : 


I .  Program  Controls 

The  following  data  sets  Input  parameters  that  control  the 
running  of  the  code,  the  decision  logic  used,  the  outputs  pro¬ 
duced  and  scenario  parameters  such  as  the  length  of  (clock)  time 
of  the  encounter. 

1.  DECISION  RULES.  This  command  allows  resetting  certain 
default  conditions  and  values  that  control  the  rules  by  which  the 
allocation  algorithm  chooses  assets  for  assignment  into  the  vari¬ 
ous  LINKS.  The  allocation  algorithm  (commander)  normally  consid¬ 
ers  versatility  before  considering  the  order  in  which  the  user 
listed  assets  on  a  substitution  card.  (See  LINKS,  section  H.4.) 
This  command  allows  choosing  whether  versatility  or  user- input- 
order  is  to  be  the  first  consideration.  (See  ALLOCATION  DECISION 
RULES,  section  B.7.) 

Format:  (HR) 

DECISION  RULES 

PRIORITY,  first  consideration 

where : 

first  consideration  is  VERSATILITY  (default)  or  ORDER 

Option:  Significance.  This  option  allows  specifying  the  frac¬ 
tional  improvement  needed  before  the  allocation  algorithm  will 
ignore  differences  in  order  and  versatility.  (e.g.,  signif  =  0.5 
means  that  an  asset  having  1.5  times  the  effectiveness  of  the 
current  best  choice  will  automatically  become  current-best- 
choice,  regardless  of  versatility  or  order.) 

Format;  (Rl) 

SIGNIFICANCE,  signif 

where : 

signif  is  the  required  improvement  (REAL) . 

Default,  signif  =  0.005. 

Option;  Sickness  level.  This  option  allows  specifying  the 
degraded  level  of  performance  (e.g.,  due  to  sickness  or  fatigue) 
that  an  asset  must  show  in  order  to  be  pre-empted  in  its  HOMELINK 
by  a  substitute.  (e.g.,  sicklv  =  0.75  means  that  if  a  homelink 
asset  were  at  effectiveness  0.5  and  a  substitute  were  available 
at  effectiveness  greater  than  0.67  (  =  0.5  /  0.75  ),  then  the 
homelink  asset  would  be  replaced  in  his  job.) 

Format;  (Rl) 

SICKNESS,  sicklv 

where : 

sicklv  is  the  required  degradation  (REAL) .  Default, 
sicklv  =  0.75. 

Option;  Finish  repair.  This  option  allows  specifying  the  rela¬ 
tive  worth  in  finishing  an  ongoing  NEEDED  repair  rather  than 
starting  another  NEEDED  repair.  (e.g.,  fnshrp  =  2.0  means  that. 


If  an  ongoing  repair  has  0.6  of  an  Item  left  to  fix,  the  code 
will  calculate  the  anticipated  gain  based  upon  receiving  1.2  (  - 

2.0  *  0.6  }  Items.  This  would  be  compared  to  the  anticipated 

gain  from  any  other  repair  which  might  be  Initiated  In  order  to 
solve  a  mission-accomplishment  limitation.  The  repair  which 
promises  the  most  gain  Is  the  one  selected  by  the  optimization 
algorithm  to  add  to  the  mission  requirements  to  calculate  the 
mission  cost  of  (NEEDED)  repair.  See  Repair,  section  D.7.  Note 
that  this  parameter  only  Influences  NEEDED  repairs,  as  defined  In 
section  D.7. } 

Format:  (Rl) 

FINISH  REPAIR,  fnshrp 

where : 

fnshrp  Is  the  relative  gain  (REAL) .  Default,  fnshrp  « 

2.0 


2.  GO.  This  command  Indicates  that  all  data  has  been  entered 
and  the  simulation  and  analysis  should  begin. 

Format:  (not  applicable) 

GO 


3.  GRANULARITY.  This  option  causes  the  Iterative  portion  of  the 
optimal  allocation  processor  to  consider  allocating  an  asset  in 
specified  portions,  thus  decreasing  the  possibility  of  over¬ 
allocating  to  one  task  at  the  detriment  of  others,  since  the 
optimization  algorithm  has  built-in  checks  against  such  over- 
allocation,  this  option  Is  not  used  except  as  a  code  development 
and  dlagnoslc  tool. 

Format : 

GRANULARITY 
asset  name,  grnl 

where : 

grnl  is  the  largest  increment  per  allocation  step  (REAL) 


4.  HEADING.  This  option  allows  the  user  to  write  a  message  at 
the  beginning  of  the  AURA  output  and  again  at  the  beginning  of 
the  results.  This  message  Is  In  addition  to  any  message  entered 
via  the  computer  normal  Input  channel  during  execution.  (See 
EXECUTION,  section  A.) 

Format : 

HEADING 

message 


5.  INTERNAL  RECONSTITUTION  TIMES.  This  option  Inputs  a  matrix 
of  times  (Intervals)  following  a  lethality  or  reconstitution 
event  at  which  outputs  are  desired.  Every  lethality  event  (see 
ROUND  and  VOLLEY,  sections  F.5  and  F.9)  and  reconstitution  event 
(see  RECONSTITUTION  EVENT,  section  1.8)  causes  the  Internal  clock 
to  reset.  Then,  at  the  end  of  Interval  1,  Interval  2,  etc.,  the 
code  updates  all  time  dependent  factors,  reallocates  assets,  and 
compiles  all  statistics  to  be  used  In  the  final  results.  In  this 
way,  the  user  sets  up  the  time  points  at  which  results  will  be 
reported . 

Format:  (RO) 

INTERNAL  RECONSTITUTION  TIMES 

tml,  tm2,  tm3,  ...  (maximum,  47  times) 

where : 

tml  Is  the  Ith  time  point  (Intrvl)  after  a  lethality 
event 


6.  MODE.  This  option  controls  certain  choices  in  operation  of 
the  code. 

Option:  CODE  mode.  Used  in  code  development  to  track  internal 
parameters . 

Format:  (HR) 

MODE 

CODE,  ON  or  OFF  (Default  *  OFF) 

Option:  CULL  mode.  In  CULL  mode,  incoming  rounds  are  screened 
(in  the  ROUND  and  VOLLEY  input  routines)  to  predetermine  if  the 
round  has  a  potential  of  affecting  a  target  point.  This  allows 
using  one,  standard,  large,  scenario-wide  threat  in  the  run- 
streams  for  all  targets  in  the  the  scenario:  AURA  will  cull  out 
only  those  weapon  employments  which  might  affect  the  unit  being 
studied  in  each  runstream.  NOTE:  If  running  in  CULL  mode, 

weapon  employment  data  (ROUND  or  VOLLEY)  may  not  be  followed  by 
weapon  characteristic  data  (DEPLOY,  DELIVERY,  TLE,  CONVENTIONAL, 
or  TOXIC.) 

Format:  (HR) 

CULL,  ON  or  OFF  (Default  =  OFF) 

Option:  DEBUG  mode.  Causes  the  code  to  process  input  data  but 

not  execute.  Used  to  debug  runstreams. 

Format:  (HR) 

DEBUG,  ON  or  OFF  (Default  =  OFF) 

Option:  PRIORITY  mode.  Changes  the  interpretation  of  Compound 
Links.  In  PRIORITY  mode,  parts  of  compound  links  (cpparts)  are 
considered  in  order  of  entry  AND  failure  to  improve  one  cppart 
stops  the  optimization  process.  If  the  following  restrictions 
apply: 

a.  unit  structure  consists  of  a  single  compound  link  whose 
cpparts  are  all  simple  subchains 

b.  every  link  is  modeled  as  a  0.-  1.  step  function  (i.e.  a 
job  is  either  at  100%  or  else  0%) 

c.  all  substitutes  are  100%  capable 

d.  degradation  of  assets  is  not  played 

e.  multiple  assets  cannot  be  assigned  to  a  single  job 

then  PRIORITY  mode  causes  the  AURA  optimization  algorithm  to 
emulate  the  AMORE  linear  program  allocation  algorithm. 

Format:  (HR) 

PRIORITY,  ON  or  OFF  (Default  =  OFF) 

Option:  STOCHASTIC  mode.  Causes  all  lethality  assessments  to  be 
stochastically  determined.  In  STOCHASTIC  mode,  the  AURA  lethal¬ 
ity  routines  draw  random  numbers  against  calculated  probabilities 

to  determine  damage  or  kill,  (in  normal  mode,  fractional  kills  are  tallied.; 


Fomat:  (HR) 

STOCHASTIC,  ON  or  OFF  (Default  -  OFF) 

Option:  TIME  BEFORE  ZERO.  This  option  allows  resetting  the 
assumed  time  that  has  elapsed  before  start  of  analysis,  thus  lim¬ 
iting  the  substitutions  that  can  be  assumed  for  the  time  -  0. 
reconstitution.  The  default  time.  Infinite,  allows  all  needed 
sxibstltutlons  to  be  made  before  commencement  of  analysis. 

Format:  (Rl) 

TIME  BEFORE  ZERO,  time  (Intrvl)  (REAL) 


7.  OUTPUT.  This  option  controls  the  printing  of  optional  out¬ 
puts  from  an  AURA  run.  The  definition.  Interpretation  and  use  of 
these  outputs  Is  the  svibject  of  a  report  to  be  published. 


I########################*###########*## 

The  OUTPUT  Options 


BINS  FATIGUE 

CASUALTIES  *  INPUT  LISTING 
CHAIN  ITERATION 

DEPWYMENT  LETHALITY 

DOSE  *  LINK  SUMMARY 

DUMPS  OPTIMIZE 

DUMPS  POSTURE  * 

ETIPCI 

*  -  Indicates  options  affected  by  PARTICULAR  ASSETS  option 


PRINT 

RANDOM  NUMBER 

RECONSTITUTION 

REPAIR  REPORT 

SUMMARY 

TIMER 

WEAPON 


Option:  BINS.  Reports  the  contents  of  all  radiation 
accxmtulation  bins  for  every  asset  at  reporting  times  that  fall 
within  the  specified  Intervals. 

Format:  (Rl) 

BINS,  strtl,  stpl,  strt2,  stp2,  .... 

where: 

strtl  is  the  start  time  (clock)  for  the  Ith  intexrval 
(REAL) 

stpl  is  the  ending  time  (clock)  for  the  Ith  interval 
(REAL) 

Default,  no  bln  reports  output. 


Option:  CASUALTIES.  Reports  all  casualties,  contaminations,  ETI 
episodes  and  expenditures  as  they  occur.  If  WEAPON  report  is  not 
ON,  this  option  also  describes  incoming  warheads  which  cause 
Immediate  casualties.  (See  PARTICULAR  ASSETS  option.) 

Format:  (HR) 

CASUALTIES,  ON  or  OFF  (Default,  OFF) 


Option:  CHAIN.  Prints  line-printer  depiction  of  unit  functional 
structure . 

Format:  (HR) 

CHAIN,  ON  or  OFF  (Default,  ON) 


Option:  DEPLOYMENT  PLOT.  Prints  line-printer  depiction  of  unit 
deployment.  Including  initial  wind  and  incoming  fire  directions. 
(See  SELECTIVE  PLOT  option.) 

Format:  (HR) 

DEPLOYMENT  PLOT,  ON  or  OFF  (Default,  ON) 


Option:  DOSE.  Reports  all  nuclear  or  toxic  doses  as  received 
(cxunulated  to  the  nearest  reporting  time) .  (See  PARTICULAR 
ASSETS  option.) 

Foinaat:  (HR) 

DOSE,  ON  or  OFF  (Default,  OFF) 


Option:  DUMPS.  Causes  reallocation  information 

(time,  effectiveness,  weak  LINKS,  strongest  CHAIN)  to  be  written 

onto  output  unit  #8  at  every  reporting  time. 

Format:  (HR) 

DUMPS,  ON  or  OFF  (Default,  OFF) 


Option:  « DUMPS.  Causes  incoming  weapon  information,  including 
actual  burst  points  for  every  warhead  in  every  replication,  to  be 
written  onto  output  unit  #9.  This  information  is  used  by  the  BRL 
graphical  post-analysis  utility  programs  to  aid  in  analysis  of 
results . 

Format :  (HR) 

DUMP9,  ON  or  OFF  (Default,  OFF) 


Option:  ETIPCI.  If  ON,  causes  at-end  average  of  nuclear  dose 
effects  (average  performance  degradations.  Early  Transient 
Incapacitation  episodes  and  Permanent  Incapacitation  occurrences) 
to  be  printed.  If  FULL,  also  causes  intermediate  information  to 
be  written  onto  output  unit  #10. 

Format:  (HR) 

ETIPCI,  ON  or  FULL  or  OFF  (Default,  ON) 


Option:  FATIGUE.  If  RECONSTITUTION  (see  below)  is  ON  or 
PARTIAL,  this  option  prints  out  the  fatigue  status  of  all  assets. 

Format:  (HR) 

FATIGUE,  ON  or  OFF  (Default,  OFF) 


Option:  INPUT  LISTING.  Causes  the  code- Interpreted  input  data  to 
be  printed  at  beginning  of  output. 

Format:  (HR) 

INPUT  LISTING,  vordl,  word2,  word3,  ... 
where :  word  ■ 


ON  to  turn  on  full  beginning  output  (Default) 

OFF  to  turn  off  all  beginning  output 
EVENTS  to  print  event  table 
WEAPON  to  print  weapon  identification  table 
ASSETS  to  print  asset  identification  table 
NUCLEAR  to  print  nuclear-related  parameters 
TOXIC  to  print  toxic-related  parameters 
REPAIR  to  print  failure  and  repair  parauneters 
LINKS  to  print  link  definition  table 

FUNCTIONAL  to  print  substitution,  subchain,  orlink  and 
cplink  tables 

DEPLOYMENT  to  print  deployment  table 


Option:  ITERATION.  Causes  some  results  to  be  reported  at  the  end 
of  every  replication. 


Format: 


ITERATION,  ON  or  OFF  (Default,  OFF) 


Option:  LETHALITY.  Causes  input  units  #2,  #3,  and/or  #4  (conventional 
lethality  file,  nuclear  vulnerability  file,  and  toxic  dispersion 
file,  respectively)  (if  used)  to  be  rewound  and  copied  onto  the  end 
of  the  AURA  output. 

Format:  (HR) 

LETHALITY,  ON  or  OFF  (Default,  ON) 


Option:  LINK  SUMMARY.  Causes  an  at-end  report  of  the  number  of 
times  the  specified  links  were  weak  at  each  reporting  time  as  a 
function  of  the  chain  being  optimized. 

Format:  (HR) 

LINK  SUMMARY,  linkl,  llnk2,  ...  (maximum,  12) 
or  LINK  SUMMARY,  OFF  (Default,  OFF) 


Option:  OPTIMIZE.  Causes  a  highly  detailed  report  of  every  step 
attenpted  In  every  optimal  reallocation  process  which  occurs 
during  the  specified  Intervals. 

Format:  (Rl) 

OPTIMIZE,  strl,  stpl,  str2,  stp2,  ...,  lunvlk 

where: 


strl 

Is  the  start  time 
(REAL) 

(clock) 

for 

the 

Ith 

Interval 

stpl 

Is  the  ending  time 
(REAL) 

(clock) 

for 

the 

Ith 

Interval 

lunwlk  Is  an  optional  flag  to  redirect  this  output 
(INTEGER) 


lunwlk  .GE.  0  -  output  on  printer 

.LE.  0  -  output  on  output  unit  #13 
(Default,  lunwlk*!) 

Default,  no  optimization  steps  reported. 


Option:  PARTICULAR  ASSETS.  Restricts  the  assets  to  be  Included 
In  casualty  reports,  dosages,  contamination  reports,  etc. 

Format:  (HR) 

PARTICULAR  ASSETS,  asset  namel,  asset  name2,  ... 

NOTE:  Common  names  can  be  used;  any  nxunber  of  assets  can  be 
Included. 


Option:  POSTURE.  Causes  a  report  of  all  posture  changes.  If 
ON,  every  Individual  Is  reported;  If  PARTIAL,  group  changes  are 
reported.  (See  PARTICULAR  ASSETS  option.) 

Format:  (HR) 

POSTURE,  ON  or  PARTIAL  or  OFF.  (Default,  OFF) 


Option:  PRINT?.  Causes  all  output  to  be  sent  to  output  unit  #7. 
Format:  (HR) 

PRINT?,  ON  or  OFF.  (Default,  OFF) 


Option:  RANDOM  NUMBER.  Causes  repoirt  of  the  random  number  seeds 
at  the  beginning  of  each  replication. 

Format:  (HR) 

RANDOM  NUMBER,  ON  or  OFF  (Default,  ON) 


Option:  RECONSTITUTION.  Causes  output  after  every 
reconstitution.  If  ON,  a  complete  matrix  of  assets  assigned 
versus  LINKS  is  produced.  If  PARTIAL,  only  a  siunmary  of  results 
with  a  report  of  assignments  into  the  weak  LINK  is  given.  If 
ONCE,  a  complete  matrix  of  asset  assignments  is  given  for  the 
initial  arrangement  only.  If  time  Intervals  are  specified,  a 
complete  matrix  of  asset  assignments  is  reported  for  any 
reconstitution  which  occurs  during  the  specified  intervals. 


Format: 


or 

where: 


(HR) 

RECONSTITUTION,  ON  or  PARTIAL  or  ONCE  or  OFF.  (Default, 
OFF) 

RECONSTITUTION,  strl,  stpl,  Str2,  stp2,  ... 

strl  is  the  start  time  (clock)  for  the  Ith  interval 
(REAL)  stpl  is  the  ending  time  (clock)  for  the  Ith 
Interval  (REAL) 


Option:  REPAIR  REPORT.  If  ON,  causes  a  report  of  all  repair 
activities  at  each  reporting  time.  If  FULL,  also  gives  a 
complete  status  of  damaged  items  available  for  repair  at  each 
time. 

Format:  (HR) 

REPAIR  REPORT,  FULL  or  ON  or  OFF.  (Default,  OFF) 


Option:  SELECTIVE  PLOT.  Restricts  the  assets 

depicted  in  the  line-printer  deployment  plot.  (See  DEPLOYMENT 

PLOT  option.) 

Format: 

SELECTIVE  PLOT,  asset  namel,  asset  name2,  ... 


NOTE:  Common  names  can  be  used;  any  number  of  assets  can  be 
included.  Default:  all  assets  included. 


Option;  SUMMARY.  Gives  an  at-end  sum  of  survivors  vs.  time, 
with  standard  deviations  of  the  averages  over  replications.  This 
output  eliminates  the  need  to  add  up  the  final  output  results  for 
several  assets.  The  user  need  only  give  the  assets  a  common  name 
(see  NAMES,  section  C.)  and  request  a  summary  on  the  common  name 
via  this  option.  Commonly  used  to  summarize  total  casualties  for 
PERSONNEL. 

Format;  (HR) 

SUMMARY,  common  namel,  common  name2,  ...  (maximum,  6) 
or  SUMMARY,  OFF  (Default,  OFF) 


Option;  TIMER.  Allows  user  to  measure  the  computer  time  used  by 
various  portions  of  an  AURA  run. 

Format;  (HR) 

TIMER,  opt 
where  opt  is; 

ON;  times  major  segments 
OFF;  no  timing 

INPUT:  times  the  input  and  preprocessor  routines 

OPTIMIZATION:  times  the  various  routines  in  the 

optimal  allocation  process 

RECONSTITUTION:  times  over-all  reconstitution  process 

(  updating,  inventory,  optimization,  etc.  ) 


Option;  WEAPON.  Causes  a  report  of  every  weapon  arrival  (type, 
time,  aimpoint,  burstpoint) . 

Format;  (HR) 

WEAPON,  ON  or  OFF  (Default,  OFF) 


##«###############«#########«####««##### 


8.  RECONSTZTDTIOil  EVENT.  This  option  causes  a  reset  of  the 
internal  time  clock  to  restart  a  series  of  output  time  points. 
(See  INTERNAL,  section  1.5.) 

Format:  (RO) 

RECONSTITUTION  EVENTS 
timel,  time2,  ... 

where: 

timel  is  the  Ith  (clock)  time  from  which  a  series  of 
reporting  times  will  be  generated.  (REAL) 


9.  REPLICATIONS.  This  option  controls  the  number  of  replica¬ 
tions  to  be  done. 

Format:  (RO) 

REPLICATIONS 

number  of  replications  (INTEGER) 


10 .  SEEDS  (Random  Niimber) .  This  option  allows  presetting  the 
random  number  seeds  before  beginning  a  run.  This  option  is  par¬ 
ticularly  useful  if  one  wishes  to  repeat  one  particular  replica¬ 
tion  of  a  previous  run,  perhaps  with  special  output  options 
turned  on.  Note  that  there  are  a  number  of  random  number 
sequences,  each  with  its  own  seed,  maintained  in  AURA. 

Format:  (Rl) 

SEEDS  (RANDOM  NUMBER) 
sdnm,  seedvalue 

where : 

sdnm  is: 

WEAPON,  to  set  seed(l)  which  primarily  effects 
weapon  delivery  processes 

OTHER,  to  set  seed (2)  which  effects  processes 
not  specifically  seeded 

FAILURE,  to  set  seed (3)  which  effects  random 
failures 

STOCHASTIC,  to  set  seed (4)  which  is  used  to 
select  kills  in  stochastic  mode.  (See  MODE, 
section  1.6.) 

HEAT  CASUALITIES,  to  set  seed (5)  which  selects 
heat  stress  casualties 
seedvalue  is  the  desired  seed  (REAL) 

Defaults  set  by  code. 


11.  STOP.  This  command  indicates  the  end  of  the  runstream  file. 

Format:  (not  applicable) 

STOP 


12.  TRACE.  This  option  causes  reporting  of  specified  LINKS 
being  used  or  specified  LINKS  being  weak.  Useful  as  an  aid  to 
tracking  down  erratic  or  Inexplicable  link  behavior. 

Format:  (HR) 

TRACE 

WEAK  LINK,  link  name,  rec 
or  USES,  link  name,  rec 

where : 

rec  Is  the  reconstitution  number  of  Interest  (l.e.  the 
reconstitution  In  which  a  use  or  weak  link 
occurrence  of  the  specified  link  Is  to  be 
reported) . 
or 

rec  can  be  the  word  ANY  to  report  all  such 
occurrences . 
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III.  SUMMARY 


This  manual  has  presented  the  current  repertoire  of  commands 
for  the  Army  Unit  Resiliency  Analysis  (AURA)  computer  code.  It 
is  clear  from  the  number  and  diversity  of  commands  that  the 
methodology  is  extremely  flexible,  with  algorithms  designed  to 
model,  in-depth,  a  large,  broad,  detailed  spectrum  of  battlefield 
factors. 

Not  covered  in  this  report  are  the  efforts  being  pursued  at 
the  Ballistic  Research  Laboratory  to  facilitate  the  use  of  AURA 
among  users  of  differing  technical  and  computational  backgrounds. 
The  first  of  these  efforts  are  those  dealing  with  aiding  input 
preparation.  Already  in  existence  are  interactive  graphical  pro¬ 
grams  for  the  generation  of  deployment  data.  These  are  being 
augmented  with  graphical  packages  for  the  generation  of  unit 
functional  structure  diagrams  and  data  and  off-line  debugging 
routines. 

Of  particular  importance  is  the  work  being  done  to  create 
standard  data  bases  for  such  AURA  inputs  as  weapon  characteris¬ 
tics,  vulnerability/ lethality,  unit  structures  and  deployments. 
It  is  currently  envisioned  that  these  data  bases,  wherever 
resident,  will  be  accessible  through  DoD  computer  nets  to  allow 
user-friendly,  interactive  input  file  assembly  by  non-experts  in 
the  various  technical  areas.  A  nuclear  vulnerability  data  base 
has  long  been  available  from  the  Harry  Diamond  Laboratory. 
Although  quite  incomplete,  joint  efforts  by  the  HDL  and  the  BRL 
have  resulted  in  a  quick,  easy-to-use  tool  for  the  preparation  of 
nuclear  vulnerability  data  files  (input  unit  #3)  for  AURA  nuclear 
runs.  Work  at  the  BRL  has  begun  on  the  conventional  lethality 
data  base. 

Finally,  a  set  of  interactive  programs,  perhaps  involving 
expert  system  techniques,  are  planned  to  facilitate  the  analysis 
of  AURA  results.  The  currently  operational  actual-weapon-burst- 
point  graphical  extension  to  the  deployment  program  is  the  first 
of  these  aids. 

The  goal  of  these  efforts  is  to  make  it  feasible  for  one¬ 
sided  unit-level  analyses  to  be  made  quickly,  easily,  and  uni¬ 
formly  throughout  the  diverse  Army  analysis  cojnmunity,  using  the 
most  current  data  and  algorithms  available  from  the  various  pro¬ 
ponent  agencies.  It  is  intended  that  the  publication  of  this 
manual  will  be  a  first  step  toward  that  goal. 


conventional  Lethality  (Unit  #2) 

The  conventional  lethality  file  inputs  a  weapon  name  (which 
may  be  a  common  name)  as  it  appears  in  the  WEAPON  list  under  the 
NAMES  mnemonic  in  the  runstream  file.  Following  the  weapon  name 
are  a  series  of  asset  names  (which  also  may  be  common  names}  from 
the  ASSET  list  under  NAMES.  Under  each  asset  name  is  a  list  of 
conditions,  followed  by  the  parameters  that  describe  the  vulnera¬ 
bility  of  the  asset  to  the  weapon  under  the  conditions  listed. 

Three  conditions  are  covered  in  the  lethality  data: 
height-of-burst  (HOB)  of  the  incoming  weapon,  posture  of  the 
asset  and  kill  criteria.  The  format  of  the  input  routine 
requires  that  lethality  data  be  given  for  all  combinations  of  the 
three  conditions.  Thus,  if  two  HOB,  four  postures  and  three  kill 
criteria  are  listed,  there  must  be  24  (  2*4*3  )  lethality  data 
lines. 

Lethality  data  may  be  in  one  of  eight  forms.  All  data  for  a 
single  weapon-asset  combination  must  be  in  the  same  form;  how¬ 
ever,  different  forms  may  be  used  for  different  assets  under  a 
single  weapon.  The  data  form  used  for  each  asset  is  indicated  by 
an  integer  code  n\nnber  on  the  asset  name  card. 

The  allowed  forms  are:  a  single  ellipse,  two  or  three  con¬ 
centric  ellipses  and  the  Carleton-von  Neumann  (bi-variate  Gaus¬ 
sian)  function.  Each  of  the  above  can  also  be  input  with  dif¬ 
ferent  elliptical  or  Gaussian  parameters  for  the  positive  and 
negative  RANGE  (forward-backward)  directions.  Code  numbers  (  2- 
10  )  for  the  various  forms  are  listed  in  Table  A-1. 

TABLE  A-1.  Conventional  Lethality  Data  Types  and  Required  Data 
CODE  DATA  TYPE  REQUIRED  DATA 


2 

3 

5 

6 

7 

8 

9 

10 


Carleton-von  N 
Single  ellipse 
Double  ellipse 
Triple  ellipse 
Asymmetric  C-von  N 
Asymmetric  ellipse 
Asym.  double  ellipse 
Asym.  triple  ellipse 


PkO,sigR,sigD 

Pk0,r0R,r0D 

PkO , rOR, rOR, Pkl , rlR, rlD 

PkO , r OR , r OD , Pkl , r IR , r ID , Pk2 , r 2R , r 2D 

PkO , sigR+ , slgD, sigR- 

PkO , r 0R+ , r OD , r OR- 

PkO , rOR+ , rOD, rOR- , Pkl , rlR+ , rlD, rlR- 
PkO , rOR+ , rOD, rOR- , Pkl , rlR+ , . . . . 


Note:  Code  numbers  1  and  4,  originally  used  for  data  types  that 
are  no  longer  supported,  are  currently  disabled. 
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Repairable  Combat  Damage  Lethality  Data 

Data  for  the  probability  of  repairable  combat  deunage  from 
conventional  weapons  is  input  using  the  same  formats  described  in 
this  section.  There  are,  however,  two  restrictions  on  the  values 
of  the  data  input: 

1.  There  must  be  exactly  three  kill  criteria  specified:  damage 
requiring  light  repairs,  damage  requiring  medium  repairs, 
and  damage  unfixable  by  the  study  unit. 

2.  The  probabilities  corresponding  to  light,  medium  and  unfix¬ 
able  must  be  mutually  inclusive;  i.e.  probability  of  light 
damage  means  "probability  of  AT  LEAST"  light  damage. 
Therefore,  for  any  given  incoming  round  (HOB,  posture  of 
the  target,  miss-distance) ,  the  probability  of  light  damage 
must  be  greater  than  or  equal  to  the  probability  of  medium 
damage.  Similarly,  probability  of  medium  damage  includes 
probability  of  unfixable. 


62 


Format  for  Conventional  Lethality  File  (Unit  §2) 


weapon  name 

asset  namel,  data  type  code  (per  Table  Al) 
number  of  HOBs  (INTEGER),  heights  of  burst (REAL) 
niimber  of  postures  (INTEGER) ,  verbal  descriptions 
number  of  kill  criteria  (INTEGER) ,  verbal  descriptions 
data 


Example  of  Conventional  Lethality  Data  File 

WARHEADl 
SUPPLIES,  3 
2,  0. ,  20. 

1,  IN  THE  OPEN 

1,  UNUSABLE 
1.0,  19.2,  14.3 
1.0,  22.7,  18.1 
TRUCK,  8 

1,  10. 

2,  IN  THE  OPEN,  IN  THE  TREES 

3,  LITE,  MEDIUM,  HEAVY  DAMAGE 

1.0,  22.6,  14.4,  10.7,  0.3,  30.3,  22.3,  12.3 
1.0,  18.4,  11.1,  5.9,  0.3,  24.6,  16.6,  8.8 
1.0,  10.2,  8.3,  2.2,  0.3,  16.2,  12.2,  5.5 
1.0,  18.8,  11.5,  6.6,  0.3,  25.0,  16.6,  9.0 
1.0,  10.4,  8.5,  2.8,  0.3,  16.7,  12.6,  5.9 
1.0,  6.2,  4.2,  0.9,  0.3,  10.4,  8.5,  2.3 
WARHEAD2 
SUPPLIES,  5 
1,  8. 

1,  OPEN 
1,  RUINED 

1.0,  19.3,  19.3,  0.3,  22.9,  22.9 
TRUCK,  8 


Nuclear  vulnerability  Data  for  Equipment  (Unit  #3) 


Unlike  the  case  of  conventional  lethality,  in  which  there  is 
a  distinct  data  entry  for  every  combination  of  weapon,  target, 
height-of-burst,  posture  and  kill  criteria,  the  shallow  gradient 
of  nuclear  effects  allows  the  Insertion  of  an  intermediate  step: 
Weapons  produce  a  set  of  environments  and  vulnerability  of  tar¬ 
gets  is  assessed  as  a  function  of  environmental  strength.  The 
environments  included  in  the  current  Harry  Diamond  Laboratory 
(HDL)  nuclear  vulnerability  data  base,  and  hence  calculated 

within  AUHA,  are  blast-overturn  (dP*Ig) ,  neutron  fluence  (TREE) , 
electro-magnetic  pulse  (EMP)  and  thermal  fluence. 

Because  all  weapon  events  are  converted  to  environments, 
only  one  card  (data  line)  is  required  for  each  target.  The  card 

contains:  the  ASSET  name  (may  be  a  common  name)  as  it  appears 

under  ASSETS  in  the  NAMES  section  of  the  AURA  runstream,  a  code 
number  which  indicates  the  environments  to  which  the  item  is  sus¬ 
ceptible,  and  the  required  data.  The  code  nvimber  and  the 

required  data  are  taken  directly  from  the  HDL  NUDACC  data  base. 

The  code  number  defined  by  HDL  is  found  by  adding  together  a 
digit  assigned  to  each  environment.  These  digits  are: 

1  -  EMP 

2  -  TREE 

4  -  dPIq 

8  -  Thermal 

Thus,  the  vulnerability  data  for  an  item  susceptible  to  EMP  and 
blast-overturn  would  have  code  number  5  (  =  1  +  4  ) .  The  data 
itself  is  a  set  of, parameters  for  a  shifted  log-normal  probabil¬ 
ity  distribution.  The  data  required  for  each  environment  is 

presented  in  the  following  table. 


A-1.  William  L.  Vault,  "Vulnerability  Data  Array:  The  Agreed 

Data  Base  -  Final  Report  (U),"  Harry  Diamond  Laboratories, 
HDL-TR-1906,  (JUL  80) ,  (SECRET). 


TABLE  A-2.  Data  Raqulred  for  vulnerability  Calculations 
Environment 


ENVIRONMENT 


DATA  REQUIRED 


EMP  log-mean,  log-slgma 

TREE  transmission,  log-mean,  log-slgma 

dPIq  threshold  shift,  log-mean,  log-slgma 

Thermal  damage  fluence,  dummy  variable 


Example  of  Nuclear  Vulnerability  File  (Unit  §3) 


RADIO,  3,  1.6,  2.6,  1.0,  10.68,  3.2 
TRUCK,  4,  2.2,  3.5,  2.56 


Toxic  Dispersion  File  (Unit  #4) 


The  toxic  dispersion  file  requires  up  to  three  sets  of  data 
derived  from  a  dissemination  code  such  as  the  NUSSEII  code 
from  the  Chemical  Research  and  Development  Center  (CROC) .  The 
number  of  data  sets  required  depends  upon  the  threat  environments 
(contamination,  percutaneous,  vapor)  to  be  included  from  each 
warhead.  The  first  set  of  data,  the  cont2unination  outline,  gives 
the  width,  arrival  and  evaporation  time  of  contamination  as  a 
function  of  downwind  distance.  The  second  set,  also  taken  from 
the  liquid  phase  of  the  dissemination  calculation,  is  a  grid  of 
contamination  density,  normalized  to  a  lethal  percutaneous  dose, 
for  crosswind  displacements  as  a  function  of  downwind  distance. 
The  third  set  is  a  series  of  dosage  grids,  one  for  each  selected 
time  point,  with  each  grid  containing  an  entry  for  dosage  at  each 
crosswind  displacement  as  a  function  of  downwind  distance.  In 
the  third  set,  all  entries  are  normalized  to  a  lethal  inhalation 
dose. 


It  was  foreseen  that  the  eunount  of  data  needed  to  fully 
describe  the  behavior  of  a  toxic  threat  was  prohibitively  pon¬ 
derous  to  enter  manually.  Therefore,  the  BRL  developed  a  utility 
code  which  interfaces  with  the  NUSSEII  code  to  interactively  gen¬ 
erate  the  required  data  sets.  Unfortunately,  the  only  standard 
outputs  available  from  the  NUSSEII  code  are  for  hard-copy  print 
files,  and  are  therefore  laced  with  a  prohibitively  cumbersome 
number  of  titles,  spaces  and  other  reader-friendly  formats. 
Therefore,  the  BRL  also  has  extended  each  version  of  NUSSEII 
which  it  has  received  to  include  a  simple  formatted  d\mp  of  the 
contamination,  primary  vapor  and  total  vapor  grids.  It  is  upon 
this  file  that  the  BRL  utility  code  PRETOX  operates. 


To  use  PRETOX,  the  user  responds  to  the  following  prompts. 

WHAT  TIME  UNIT  IS  BEING  USED  IN  AURA  RUN  (IN  MINUTES)? 
.E.G.  IF  RUN  IS  IN  MINUTES,  TYPE  1.  IF  IN  HOURS,  TYPE 
60. 

NAME  OF  WEAPON  FOR  TOP  OF  FILE? 

CONTAMINATION  DATA  (Y  OR  N) ? 

If  Y:  LOWEST  CONTAMINATION  LEVEL  TO  BE  CONSIDERED? 


A-2.  Richard  Saucier,  "A  Mathematical  Model  for  the  Atmospheric 
Transport  and  Diffusion  of  a  Chemical  Contaminant,”  Chemi¬ 
cal  Systems  Laboratory,  ARCSL-TR-81071,  (NOV  81) . 


PERCUTANEOUS  DATA  (Y  OR  N) ? 

If  Y:  STANDARD  LETHAL  DEPOSITION  (FOR  NORMALIZING)? 

PRIMARY  VAPOR  (Y  OR  N)? 

TOTAL  VAPOR  (Y  OR  N)? 

The  user  usually  chooses  the  latter.  If  either  Is  Y,  the  follow¬ 
ing  prompts  occur: 

STANDARD  LETHAL  DOSE  (FOR  NORMALIZING)? 

HEIGHTS  READ:  hi,  h2,  h3,  ... 

where  hi ,  h2 , . .  are  the  heights  at  which  NUSSEII  calcu¬ 
lated  dosages 

WHICH  ONE  DO  YOU  WANT? 


The  program  then  reports  to  the  user  the  number  of  data  points 
included  in  each  data  set,  writes  the  required  data,  in  AURA  for¬ 
mat  onto  output  \init  #4,  and  exits. 


Do8«-Tiiii«  V«rfonBanc«  Degradation  Data  File  (Unit  #11) 

The  dose-time  degradation  matrices  built  into  AURA  should  be 
sufficient  for  any  routine  application  of  AURA  to  the  nuclear  or 
chemical  battlefield.  However,  special  circumstances  might  arise 
In  which  the  user  will  want  to  prescribe  a  dose-time  dependent 
behavior  onto  certain  job  positions  in  the  unit.  Provisions  have 
therefore  been  made  to  input  additional  dose-time  performance 
degradation  matrices  and  associate  them  to  a  degradation  code 
ntimber.  Input  of  the  data  is  made  through  input  unit  #11  when  so 
directed  by  the  SUBLETHAL  DOSE  DEGRADATION  command.  The  user  can 
then  use  the  SUBLETHAL  DOSE  DEGRADATION  command  as  described  in 
the  main  body  of  this  report  to  associate  the  degradation  set  to 
the  desired  LINKS. 

Format  for  Dose-Time  Degradation  File  (Unit  ill) 


18  character  description,  code  number  for  the  degradation 
set 

number  of  dose  points  (ND)  and  their  values 
munber  of  time  points  (NT)  emd  their  values 

Data  for  dosel  (  A  set  of  NT  degradation  values  } 

Data  for  dose2  (  "  ) 


Data  for  dose  ND 


The  Asset  Reallocation  (Optimization)  Model  in  AURA 

The  formulation  of  the  asset  allocation  model  in  AURA  was 
guided  by  a  number  of  essential  factors: 

1.  Asset  allocation  is  driven  by  mission  accomplishment. 
Optimum  allocation  of  surviving,  possibly  degraded  assets 
is  that  allocation  which  results  in  the  best  accomplishment 
of  the  overall  job  or  jobs  that  the  unit  must  do.  The 
asset  allocation  model  is  therefore  inseparably  tied  to  the 
unit  functional  description  model. 

2.  Military  units  vary  widely,  especially  in  their  functional 
descriptions.  To  be  of  general  use,  a  functional  descrip¬ 
tion  model  must  be  flexible  enough  to  describe  many  dif¬ 
ferent  possible  relationships  between  assets.  These  rela¬ 
tionships  should  be  user-specifiable  during  input  prepara¬ 
tion. 

3.  To  be  easily  usable,  the  elements  of  the  functional  model 
should  have  a  recognizable  association  with  actual  ele¬ 
ments.  Similarly  —  although  generally  more  difficult  to 
describe  —  the  relationships  between  model  tasks  should 
intuitively  resemble  the  relationships  between  tasks  actu¬ 
ally  done  in  the  unit. 

4.  A  somewhat  subtle,  but  pervasive  factor:  the  asset  alloca¬ 
tions  model  must  be  compatible  with  the  mathematical 
behavior  of  the  input  data.  Thus,  for  example,  if  assets 
are  to  be  degraded  (such  as  a  man  working  at  half  the  nor¬ 
mal  rate) ,  then  the  asset  allocation  model  cannot  be  int¬ 
rinsically  an  integer  model. 

5.  Of  course,  the  output  must  be  quantitative  and  must  reflect 
the  ability  of  the  unit  to  perform  the  specified  mission. 
The  reason  for  any  shortfall  must  be  traceable  (audit 
trail) . 

Guided  more  or  less  formally  by  these  factors,  we  formulated 
the  AURA  Asset  Allocation  Algorithm  (AAAA) .  The  first  step  was 
to  define  a  fundamental  building  block  and  introduce  quantifica¬ 
tion.  Following  some  work  done  for  the  Theater  Nuclear  Force 
Survivability  study  by  BUM  (in  a  model  called  CCD) ,  we  chose  the 
individual  subtask,  which  we  call  a  LINK,  as  the  building  block. 
Fundamental  in  CCD  is  the  assumption  that  the  ability  to  do  a 
subtask  depends  upon  the  amount  of  assets  allocated  to  that  sub¬ 
task. 

From  that  point,  we  deviated  from  CCD.  First,  we  general¬ 
ized  the  functional  relationship  between  the  effectiveness  of  a 
subtask  with  respect  to  overall  mission  completion  and  the  amount 
of  assets  allocated  to  the  form  shown  in  Figure  B-1.  To  illus¬ 
trate  the  flexibility  of  the  form,  note  that  the  three  graphs  in 


Figure  B2  are  just  different  cases  of  the  sane  function,  viz.,  a 
straight  line  fron  the  left  to  the  point  (N^,  E^) ,  a  slanted  line 

up  to  the  point  (^loo'  MAX),  and  a  straight  line  off  to  the 

right.  The  curves  in  Figure  B2  describe  different  kinds  of 

actual  jobs: 

TOP  CURVE:  There  is  an  optimum  amount  of  assets  (number  of 

men,  e.g.),  shown  as  at  which  the  subtask 

effectiveness  reaches  its  maximum.  Allocating 
more  assets  doesn't  add  anything  to  the  task, 
while  taking  away  assets  reduces  it. 

MIDDLE  CURVE:  Same  as  TOP  CURVE,  except  this  job  requires  a 

non-zero  minimum  number  of  assets  (N^)  to  begin  to 
get  any  effectiveness  in  the  task. 

BOTTOM  CURVE:  Some  "tasks"  have  a  residual  effectiveness,  even 
with  no  assets  assigned.  For  example,  a  well- 
trained  crew  can  function  without  a  supervisor. 
Thus,  although  the  amount  of  supervisory 

assets  may  be  required  for  maximum  performance, 
the  effective  supervisory  function  drops  only  to 

at  0  assets, 
o 

The  next  step  was  to  generalize  the  meaning  of  "amount  of 
assets"  to  include  degradations.  Thus,  putting  a  less  than  fully 
capable  man  into  a  subtask,  or  degrading  the  performance  of  a  man 
(by  putting  him  into  protective  clothing,  by  Imposing  radiation 
sickness,  etc.)  was  equated  to  allocating  less  than  a  whole 
asset  to  the  subtask.  Since  the  effectiveness  curves  (Figure  Bl) 
are  continuous,  this  generalization  required  no  change  in  the 
functional  structure.  (Note,  however,  that  the  use  of  continuous 
(non-integer)  functions  was  made  possible  by  the  development  of 
the  non-integer  (and  non-linear)  optimization  algorithm  described 
below. ) 

This  mathematical  model  of  a  subtask,  which  we  call  a  LINK, 
meets  the  requirements  for  a  quantitative  basic  building  block. 
It  is  easily  associated  with  real  jobs  (driving  a  tank,  receiving 
radio  messages),  and  smoothly  allows  for  non-integer  assets.  The 
parameters  are  also  possible  to  evaluate.  In  evaluating  an 
artillery  battery,  for  example,  one  can  ask:  How  many  gunners 
are  needed  (“N^^qq)?  Can  they  do  this  mission  (*=  MAX)?  What  hap¬ 
pens  if  there  are  none  (»  E_,  N^)? 

o  O' 

While  evaluating  the  LINK  parameters,  it  is  also  convenient 
to  ask:  Who  normally  does  this  job?  Who  can  substitute?  How 

capable  (how  much  slower)  is  the  substitute?  How  long  does  it 
take  for  the  substitute  to  take  over?  This  data  forms  the  sub¬ 
stitution  matrix,  which  is  another  fundamental  part  of  AAAA. 
Note  that  substitutes  are  governed  by  time  to  substitute  and 
relative  ability,  as  well  as  operational  and  physical  degradations. 
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Figure  B-l.  o«a«r«l  Fora  of  «  Link  Bffootivonons  Curvo 


ELEMENTS 


Figure  B-2.  Three  Examples  of  Link  Effectiveness  curves 


The  next  step  in  building  AAAA  was  to  account  for  the  dif¬ 
ferent  relationships  that  subtasks  (LINKS)  could  have  to  each 
other  with  respect  to  overall  mission  accomplishment.  First, 
some  tasks  require  others  to  also  be  effective  in  order  to  con¬ 
tribute  to  the  overall  mission.  For  example,  the  job  that  a 
forklift  operator  does  is  useless  without  the  job  that  the  fork¬ 
lift  itself  does  and  visa-versa.  Mathematically,  this  can  be 
thought  of  as  an  AND  relationship  between  the  forklift  and  fork¬ 
lift  operator  LINKS.  In  AURA,  LINKS  having  an  AND  relationship 
are  said  to  form  a  SUBCHAIN.  The  user  specifies  the  subchains  he 
wishes  to  form  via  his  input  runstream. 


Another  possible  relationship  between  LINKS  and/or  SUBCHAINS 
is  an  exclusive  OR:  In  such  cases  the  user  wants  the  code  to 
choose  the  best  of  several  alternate  ways  of  accomplishing  some 
function,  where  each  choice  (branch)  may  be  composed  of  a  single 
subtask  (LINK)  or  a  SUBCHAIN.  For  example,  it  may  be  possible  to 
use  the  forklift  team  (subchain  composed  of  forklift  and  forklift 
operator)  to  load  a  truck,  or  to  handload  it  via  crew  of  men.  In 
AURA,  the  specification  of  alternative  procedures  is  done  via  the 
ORLINK  construct. 

(Note:  The  ORLINK  is  used  for  alternative  procedures,  that 
is,  combinations  of  svibtasks,  which  perform  the  same  function. 
The  use  of  alternative  personnel  or  equipment  to  perform  the  same 
procedures  is  automatically  done  by  the  optimization  algorithm 
for  every  subtask.  In  AURA,  a  great  deal  of  care  was  taken  to 
differentiate  between  subtasks  (LINKS)  and  the  people/equipment 
which  perform  those  subtasks.  The  distinction  between  ORLINKS 
(choice  of  tasks)  and  substitutions  (choice  of  performers)  is 
just  one  manifestation  of  that  differentiation.) 

There  are  some  jobs  which  involve  a  number  of  procedures 
that  are  additively  related.  For  example,  consider  loading  a 
truck  with  75  percent  light  and  25  percent  heavy  items,  which 
retires  two  different  loading  procedures.  Clearly  the  relation¬ 
ship  between  the  two  procedures  is  not  an  OR  (only  one  is 
chosen) ,  nor  is  it  an  AND  (no  capability  unless  both  are  accom¬ 
plished)  .  Rather,  the  total  fraction  of  the  truck  loaded  is  a 
weighted  sum  of  the  light  and  heavy  loading  capabilities,  where 
the  weighting  factors,  0.75  and  0.25,  reflect  the  relative 
demands.  To  model  this  relationship,  AURA  has  a  structure  called 
COMPOUND  LINKS  (CPLINKS) .  CPLINK  parts  can  be  ORLINKS,  SUB¬ 
CHAINS,  and/or  simple  LINKS. 

The  next  higher  level  of  aggregation  is  the  CHAIN,  a  series 
of  ANDs.  The  segments  of  a  chain  can  be  CPLINKS,  ORLINKS,  SUB¬ 
CHAINS  and/or  simple  LINKS .  This  level  of  ANDs  is  convenient  for 
assembling  a  complete  mission,  which  requires  command  AND  control 
AND  communication  AND  transportation  AND . 


Finally,  a  vmit  can  be  given  a  nunber  of  missions  to  con¬ 
sider  at  any  given  time.  Each  mission  is  described  by  a  CHAIN. 
Each  CHAIN  has  a  series  of  time  intervals  during  which  the  asso¬ 
ciated  mission  is  to  be  done.  If  two  time  intervals  overlap, 
implying  two  missions  competing  for  the  unit's  attention  during 
that  time,  AUHA  chooses  the  CHAIN  which  can  be  done  most  effec¬ 
tively.  This,  in  effect,  gives  the  user  the  capability  of  an 
overall  OR  relationship  between  CHAINS. 

The  hierarchy  of  relationships  is  depicted  in  Figure  B3  and 
summarized  in  Table  B-1.  Note  that,  in  all  cases,  the  constructs 
(CHAINS,  ORLINKS,  etc.)  can  be  made  of  combinations  of  any  of  the 
lower  echelon  constructs.  This  ability  to  combine  simple  tasks, 
quantified  in  terms  of  effective  assets,  into  a  wide  variety  of 
complex  structures  gives  AAAA  the  flexibility  to  be  applied  to  a 
broad  spectrum  of  unit  types  and  missions. 


TABLE  B-1. 

HIERARCHY  OF 

RELATIONAL 

OPERATORS 

CONSTRUCT 

OPERATOR 

OPERANDS 

Operand 

May  Be 

Point  in  Time 

XOR 

CHAINS 

CHAIN 

AND 

Segments 

COMPOUND  LINK 

ORLINK 

SUBCHAIN 

LINK 

COMPOUND  LINK 

Weighted  S\im 

CP  Parts 

ORLINK 

SUBCHAIN 

LINK 

ORLINK 

XOR 

Branches 

SUBCHAIN 

LINK 

SUBCHAIN 

AND 

LINKS 

LINK 

LINK 

Fundamental  building  block 

It  is  helpful  to  consider  applying  this  structure  to  an 
example  unit.  Consider  a  small,  hypothetical  supply  unit.  The 
mission  of  the  unit  is  to  load  trucks  on  order  at  a  certain 
ratio.  Two  classes  of  items,  heavy  and  light,  are  to  be  loaded: 
the  heavy  items,  which  comprise  25  percent  of  each  load,  must  be 
loaded  with  a  crane;  the  light  items  can  be  loaded  by  hand  or  by 
forklift.  The  order  to  fill  the  trucks  is  received  by  radio  or 
telephone.  Personnel  are  required  to  receive  the  order,  man  the 
forklift  and  crane  teams,  drive  the  truck  and  handload  if 
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Flour*  B-3.  Hlararchy  of  Relationships  between  Combinations  of 


required.  Handloading,  however,  can  never  accomplish  more  than 
80  percent  of  the  required  rate  and  requires  more  than  one  per¬ 
son. 


There  is  also  a  loadma^  'r,  who  supervises  the  operation. 
However,  the  unit  has  functj.oned  together  long  enough  to  work  at 
60  percent  of  the  required  rate  even  if  the  loadmaster's  job  is 
not  done. 

A  set  of  link  effectiveness  cuirves  to  describe  this  unit  is 
shown  in  Figure  B-4.  Note  that  most  jobs  in  this  simple  example 
are  of  the  (1.,  100;  0.,  0)  form  (1  asset  for  100  percent  effec¬ 
tiveness;  0  assets  for  0  percent  effectiveness) .  Exceptions  to 
this  are  this  are  the  LOADMASTER  (1.,  100;  0.,  65)  and  the 
handloading  MEN  (5.,  80;  1.,  0). 

For  this  example,  only  one  mission  was  given.  The  CHAIN  to 
accomplish  that  mission  is  shown  in  Figure  B5.  As  described 
above,  the  mission  requires  receipt  of  the  message,  a  radio  or 
telephone,  0.75  light  and  0.25  heavy  load  capability  and  a  truck. 
The  LOADMASTER  is  also  ANDed  into  the  chain.  However,  referring 
to  Figure  B4,  one  notes  that  the  absence  of  a  loadmaster  asset 
reduces  the  value  of  the  LOADMASTER  link  only  down  to  0.6,  thus 
limiting  his  effect  on  the  unit. 

Figure  B5  is  a  graphical  depiction  of  a  CHAIN.  When  aug¬ 
mented  by  a  decision  rule,  the  figure  also  depicts  the  value 
function  upon  which  the  AURA  optimization  process  is  based.  That 
decision  rule  is: 

The  EFFECTIVENESS  of  a  ••CHAIM*'  is  EQUAL  to  the  EFFEC¬ 
TIVENESS  of  the  WEAKEST  SEGMENT. 

When  applied  to  the  example  depicted  in  Figure  B5,  this 
decision  rule  implies,  e.g.,  that  a  unit  which  had  only  one-third 
of  its  trucks  would  only  fulfill  one-third  of  its  mission,  as 
long  as  all  other  capabilities  were  greater  than  one-third.  In 
particular,  even  if  the  ability  to  receive  messages  was  degraded 
to  one-half  the  prescribed  rate,  the  unit  would  be  able  to  load 
the  available  one-third  prescribed  number  of  trucks. 
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COMPOUND  LINK 


Mathematical  Description  of  the  AURA  Asset  Allocation  Algorithm 

The  mathematical  optimization  algorithm  used  in  AURA  to 
allocate  assets  is  a  sizable  extension  of  the  GREEDY  Algorithm. 
Basically,  the  GREEDY  algorithm  solves  a  maximization  problem  by 
a  sequence  of  single  steps.  At  each  step,  the  algorithm  selects 
that  choice,  consistent  with  the  imposed  constraints,  which  pro¬ 
duces  the  maximvim  gain  in  the  value  function  (the  function  whose 
value  is  to  be  maximized) .  In  the  case  of  AURA,  the  value  func¬ 
tion  is  the  effectiveness  of  the  unit,  which  is  dictated  by  the 
value  of  the  choke  point:  The  GREEDY  algorithm  therefore  indi¬ 
cates  allocation  of  asset (s)  to  the  weakest  segment  until  its 
capability  has  Improved  above  that  of  some  other  segment,  which 
then  becomes  the  weakest.  This  process  continues  until  a  point 
is  reached  at  which  no  further  allocation  can  be  made.  Intui¬ 
tively,  this  process  corresponds  to  a  commander  considering  his 
mission's  activity  demands  one  at  a  time,  in  order  of  decreasing 
stringency  and  allocating  just  enough  assets  to  satisfy  each 
demand  before  considering  the  next  one.  The  GREEDY  algorithm  has 
been  found  to  be  a  good  model  gf^human  decision  making  in  several 
important  classes  of  problems. 

Unfortunately,  like  greedy  humans,  the  GREEDY  algorithm 
guarantees  the  optimal  solution  for  only  a  limited  class  of  value 
functions  and  constraints.  ”  In  AURA,  a  unit  whose  members  were 
completely  cross-trained  would  fall  into  that  class.  However,  in 
more  common  units,  it  is  possible  to  "fool"  the  greedy  commander, 
which  mathematically  corresponds  to  making  a  series  of  alloca¬ 
tions  which  lead  to  a  local  maximtun.  The  most  likely  way  of 
doing  this  is  to  specify  a  unit  structure  and  substitution  effec¬ 
tiveness  matrix  in  such  a  way  that  the  algorithm  chooses  asset  A 
over  asset  B  early  in  the  optimization  process,  then  cannot  fill 
a  task  that  only  A  can  do  later  in  the  sequence.  To  avoid  this 
error,  AURA  incorporates  three  processes  -  preventative  look¬ 
ahead,  local  dynamic  look-ahead  and  first-order  look-back  -  which 
intuitively  correspond  to  "experience,"  "limited  foresight"  and 
"limited  error  correction." 

In  AURA,  preventative  look-ahead  is  accomplished  in  two 
ways.  First,  a  preprocessor  evaluates  the  versatility  (i.e.  the 
number  of  possible  job  assignments)  of  each  asset.  In  all  subse¬ 
quent  allocation  events,  assets  are  considered  in  inverse  order 
of  versatility.  In  effect,  the  commander  assigns  his  least 
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useful  assets  first,  reserving  his  more-assignable  ones  for 
later.  Secondly,  before  every  allocation  event,  the  algorithm 
counts  the  actual  number  of  remaining  assets  which  could  possibly 
be  assigned  to  each  segment,  then  orders  the  segments  for  con¬ 
sideration  in  increasing  order  of  potential  assignees.  This 
corresponds  to  the  commander  knowing  that  some  jobs  may  be  hard 
to  fill  and  considering  those  jobs  ahead  of  more  redundant  ones. 

Local  dynamic  look-ahead  is  applied  to  improving  segments 
which  require  a  number  of  LINKS  (job  positions)  to  be  filled 
before  any  gain  is  realized.  In  the  truck  loading  example,  the 
commander  can  load  light  parts  by  using  a  forklift  and  operator 
or  by  assigning  several  men  to  handload.  Vfhen  AURA  considers  the 
first  alternative,  the  assignment  of  an  operator  is  made  tenta¬ 
tively;  only  when  the  forklift  is  found  to  be  assignable  and  the 
gain  from  the  two  assignments  is  recognized  is  the  set  of  assign¬ 
ments  made  "firm”.  Should  the  forklift  not  be  available,  the 
operator  remains  available  for  assignment  to  the  handloading 
crew.  This  "look-ahead”  is  applied  within  every  segment  optimi¬ 
zation  step;  however,  it  is  not  done  from  segment  to  segment. 

Finally,  first  order  look-back  is  applied  as  follows.  If  a 
point  is  reached  at  which  a  needed  asset  is  unavailable,  the 
algorithm  checks  all  previous  assignments  of  assets  which  could 
satisfy  the  need.  If  such  a  previous  assignment  is  found  and 
there  is  an  unassigned  asset  available  which  could  be  svibstituted 
for  the  needed  one,  a  "switch"  is  made:  the  unassigned  asset 
takes  the  place  of  the  needed  one,  and  the  needed  one  becomes 
available  for  reassignment  to  the  current  choke  point.  This 
look-back  is  limited  to  one  level,  however;  C  cannot  replace  B  so 
that  B  can  replace  A  so  that  A  can  become  available. 

(The  above  discussion  did  not  address  the 
REPAIR/DECONTAMINATION  model  incorporated  into  AURA.  In  AURA, 
the  commander  considers  the  possibility  of  improving  unit  perfor¬ 
mance  through  repair/ decontamination  activity.  In  order  to 
effect  repairs,  the  commander  must  allocate  the  personnel  and 
equipment  to  repalr/decon  tasks  IN  ADDITION  to  the  tasks  required 
for  his  mission.  After  determining  an  optimum  allocation  of 
resources  to  perform  this  augmented  mission,  he  weighs  the 
immediate  cost  in  mission  performance  versus  the  possible  gain  in 
deciding  whether  or  not  to  Include  the  repair/ decon  activity. 
Thus,  the  REPAIR/DECONTAMINATION  model  constitutes  a  fairly  com¬ 
plex  look-ahead  process.  However,  unlike  the  other  processes 
discussed  above,  inclusion  of  repair/ decontamination  alternatives 
is  optional . ) 

The  success  of  the  algorithm  in  solving  actual  unit  assign¬ 
ments  has  Improved  over  the  past  six  years  as  the  "commander  has 
become  smarter"  (i.e.,  as  the  above  look-ahead  and  look-back 
features  were  added) .  Mistakes  by  the  algorithm  in  actual  prac¬ 
tice  have  become  fairly  rare  and  are  usually  traceable  to 
unlikely  arrangements  of  skills  (e.g.  a  senior  person  with  a 


vinlikely  arrangements  of  skills  (e.g.  a  senior  person  with  a 
unique,  non-essential  capability  and  no  capability  to  do  the 
tasks  of  his  juniors) ,  in  conjunction  with  a  complex  unit  func¬ 
tional  structure.  As  with  any  analysis  tool,  however,  the  final 
judgement  lies  in  the  hands  of  the  analyst.  For  this  reason, 
AURA  also  Includes  several  output  options  which  can  be  used  to 
analyze  results  in  detail,  including  the  commander  decisions 
which  lead  to  the  results. 
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